Public API publication

SAVRN Cloud · Coming soon · Public preview · Browser-local simulation · No live compute or payments

Understand the preview boundary

Routes beginning with #/ select screens in this browser. They are not HTTP API endpoints. For example, Models displays fixture records and Playground runs a deterministic local sample. The preview makes no model or cloud-provisioning API call.

The demonstration's JSON exports and browser state explain proposed data relationships. They do not define a stable public request schema. Local simulated keys cannot authenticate a remote request. This guide supplies no fictional base URL or runnable-looking request against an unverified service.

What a connected API will document

A real public reference should document operation, version, authentication scope, request fields, response fields, accepted limits, errors and retry behavior. Examples should be tiny and tested. Request receipts need identifiers and accounting semantics that match the implementation.

Keep customer-visible operations separate from internal allocation, administration and operator functions.

Before connected services launch

Generate an explicit customer specification from the actual supported release. Allowlist operations and fields before publishing the schema, including downloadable and machine-readable forms. Validate examples and execute bounded acceptance requests against qualified capacity. A schema validation pass proves structure, not availability. Attach the service release, model/offer identity and supported client versions. Enable interactive request builders only after credential handling, project scope, cost behavior and mutating-operation controls have been reviewed.

A reference must let a customer predict the result

For each supported operation, a released reference should state who may call it, which project and offer it applies to, the accepted inputs and the meaning of each response field. Units matter: an output-token limit differs from a total-context limit, and a job's execution deadline differs from its maximum time in a queue. Defaults and rejection behavior are part of the contract, not implementation details the customer must infer.

A complete example should connect the request to a result identifier and its usage record. It should explain whether admission creates a reservation, when final usage settles and how the customer recognizes an uncertain outcome. A valid response shape alone cannot establish that the requested work finished or that accounting was reconciled.

Keep public documentation separate from private operations

Public reference material should contain the operations and fields a customer is entitled to use. Provider credentials, private network addresses, internal worker controls and other projects' records do not belong in that projection. Even a restricted test offer may need separate visibility rules so that its existence does not create a public availability claim.

Before a connected API is announced, its examples should be tested against the named release with authorized and unauthorized identities, supported and unsupported inputs, and interrupted requests. The SAVRN Cloud preview currently supplies explanatory JSON and simulations only. Publishing these documentation pages does not enable a production endpoint or turn a demo key into a usable credential.