Skip to main content

​
SDKs, OpenAPI & playground

A developer platform is easier to adopt when its contracts are machine-readable and its common workflows do not require hand-writing every HTTP request.

​
OpenAPI

Starfire’s Developer Platform is designed to publish a machine-readable OpenAPI description for the public API surface as the v1 contract stabilizes. OpenAPI can power:
  • reference documentation
  • request/response schema validation
  • generated SDKs
  • developer tooling
  • API explorers
  • contract testing
The exact OpenAPI URL and coverage should be taken from the active Developer Portal once the public API is enabled. Do not build tooling against an undocumented internal schema endpoint.

​
SDK direction

The initial SDK direction prioritizes:
  • JavaScript / TypeScript
  • Python
Additional languages can follow as the public API stabilizes. The SDK should remain a thin, predictable layer over the versioned API rather than hiding important concepts such as request IDs, run status, rate limits, or long-running job behavior.

​
Interactive playground

The Developer Platform design includes an interactive playground where a developer can construct a request, select eligible options, send it against the active API, and inspect:
  • request and response headers
  • JSON response
  • streaming events
  • latency
  • credits/usage
  • request identifier
A useful playground can also generate example client code such as cURL, JavaScript, or Python.

​
Streaming

SDKs should expose Starfire streaming as a first-class concept rather than forcing callers to parse transport details manually. For standard model generation, a stream can expose response lifecycle events. For FORGE or research, event streams can expose workload-specific progress stages.

​
Version compatibility

An SDK version should document which Starfire API version it targets. Major API contract changes should not be silently hidden inside a minor SDK update.

​
Production use

The playground is useful for learning and debugging. Production services should use securely stored credentials, appropriate timeout/retry behavior, and normal application observability rather than depending on a browser playground session.

API architecture

Review versioning and resource boundaries.

Logs & usage

Operate production integrations with request IDs and usage visibility.