Version the route, identify the schema, pin the client.

This is an unsupported alpha, not a stable public release. The public v1 routes are deployed, but deployment does not create an uptime, availability, production-use, or compatibility commitment. Treat every package or starter alpha bump as potentially breaking.

The six version signals

v1 philosophy

• The route version makes the external boundary visible in every URL.
• The body schema lets clients reject a response from the wrong contract.
• Strict parsers require exact keys; unexpected additions do not pass silently.
• Mocks use the same parsers and schema constants as the public routes.
• One package version and one starter version keep examples reproducible.

Breaking changes in alpha

A field addition, removal, rename, type change, new enum member, changed requiredness, different request-ID rule, or changed retry/error mapping can be breaking because the parsers accept exact shapes. During alpha, such a change requires a new alpha package and starter version. Do not assume compatibility across alpha bumps.

Additive response fields are not compatible inside the current exact v1 schemas: strict SDK parsing rejects unknown keys. A future additive capability must therefore arrive through an explicitly coordinated schema/client change, not as an unannounced extra field.

// Pin the complete generated artifact, not an unbounded alpha range.
@casset/apps   0.2.0-alpha.0
@casset/react  0.2.0-alpha.0
starter        casset-headless-react-v0.2.0-alpha.0.zip

Backwards compatibility today

Within one pinned version, the client verifies the complete response and fails closed on drift. This catches incompatibility early; it does not turn the alpha into a production service-level commitment.

Deprecation policy

No production support, uptime or availability commitment, public package channel, formal deprecation window, or sunset-header policy has been published for the deployed alpha routes. Therefore there is no production deprecation promise to rely on today. If a future supported public version ships, its compatibility and deprecation policy must be documented with that release; this alpha does not pre-announce one.

API version versus package version

v1 identifies the HTTP route family and response schemas.0.2.0-alpha.0 identifies repository-local client, React adapter, mock, and starter source. A package bump does not create a new API route, and the route name does not imply that the package is published.

Historical starter preservation

Versioned ZIP filenames are historical artifacts. Existing Native App0.1.0-alpha.0 downloads remain available alongside current0.2.0-alpha.0 downloads; they are not silently rewritten. The Headless starter begins at 0.2.0-alpha.0. No npm package publication is claimed.

Future versions

No v2 route, next schema, pagination contract, filtering contract, production credential format, or production webhook API exists. The presence ofv1 communicates a deliberate version boundary—it is not a claim that another version is scheduled or available.

Upgrade checklist

• Read the new package and starter version as potentially breaking.
• Compare route paths, schema literals, exact fields, enums, limits, errors, and retry behavior.
• Run the vendored tests and build in a fresh starter directory.
• Exercise ready, empty, terminal failure, retryable failure, and request-ID mismatch states.
• Never copy a local sandbox credential into a new archive or build artifact.

See the verified developer-platform changelogfor repository milestones without a stability promise.