Skip to main content
The Orbit Developer Platform is intended to give developers a stable way to integrate supported Orbit capabilities into their own applications.

​
8.1 Developer experience goals

  • Clear API reference and practical quick-start guides.
  • Secure API-key creation, rotation, and revocation.
  • Predictable request and response schemas.
  • Transparent rate limits and error codes.
  • Usage reporting and cost visibility.
  • Versioning and deprecation policies.
  • Test environments and example projects.
  • A support path for production issues.

​
8.2 API design principles

APIs should be consistent, explicit, and boring in the best possible way. A developer should not need to guess whether an operation succeeded or whether a field is optional. Every endpoint should document authentication, required parameters, optional parameters, response formats, failure modes, limits, and relevant data handling. Streaming behavior and tool-call semantics should be described separately from ordinary text generation.

​
8.3 Authentication and secrets

API keys should be treated as credentials. They should be displayed only when appropriate, stored using secure mechanisms, and never embedded in public client-side code or committed to a repository. Server-side applications should load secrets from environment-specific secret stores or equivalent secure configuration. A leaked key should be revocable without requiring a full account reset. Usage monitoring can help identify unusual traffic, but monitoring is not a replacement for limiting permissions and exposure.

​
8.4 Usage and billing

If paid API access is offered, pricing must clearly identify what is charged, how usage is measured, what happens when limits are reached, and whether retries incur costs. A billing interface should show enough detail for users to reconcile usage without exposing other customers’ data.

​
8.5 Versioning

Model versions and API versions are different concepts. The API contract may remain stable while the model behind a configurable alias changes, but that behavior must be explicit. Applications that require reproducibility should be able to pin a supported version when the service provides that option.