Developer Platform

Understand Starfire AI developer access, credentials, metering, and platform integration concepts.

Developer Platform

The Starfire AI Developer Platform is the programmatic surface for building software on top of Starfire instead of only using the web application.

It is intended to become a first-class Starfire product alongside the human workspace and Control Center.

Developer Platform goals

The platform is designed around several principles:

• Versioned contracts — breaking API changes belong in a new major API version.
• Scoped credentials — applications receive only the permissions they need.
• Shared metering — API usage participates in the same Starfire credit and billing foundation as web workloads while remaining distinguishable in reporting.
• Long-running work — research and FORGE builds are modeled as runs/jobs rather than forced into one synchronous response.
• Observable operations — request IDs, logs, usage, rate limits, and webhook deliveries make integrations supportable.
• Organization ownership — business integrations can belong to an organization or service account rather than one employee.

API surface

The Alpha Developer Platform architecture uses a versioned /v1 model and is designed around resources such as:

models
chat / responses
runs
research
files
artifacts
builds
projects
knowledge
embeddings
usage
webhooks

The Developer Platform is an active Alpha surface. This documentation distinguishes the designed v1 contract from what is enabled on a particular deployment. Do not treat an endpoint as production-available solely because its resource model is documented here.

OpenAI-compatible and Starfire-native APIs

Starfire’s architecture supports two complementary developer experiences:

1. Compatibility surface — familiar request shapes such as chat-completions for software already built around that ecosystem.
2. Starfire-native surface — richer APIs for capabilities that do not fit cleanly into a compatibility endpoint, such as research, long-running runs, FORGE builds, artifacts, and Starfire-specific reasoning/tool modes.

Developer portal

The intended developer portal includes:

• Overview
• API Keys
• Applications
• Webhooks
• Usage
• Logs
• Documentation
• SDKs
• Playground

Normal developers should not need Control Center administrator access to manage their own developer resources.

Long-running operations

Research and software builds can take longer than a typical request/response cycle. Starfire’s developer architecture therefore includes run IDs, status queries, cancellation, event streaming, and webhook completion events.

Security boundary

API keys and service accounts are separate from interactive browser sessions. They should be scoped, rotated, rate-limited, and auditable.

Authentication & API keys

Create and secure scoped developer credentials.

API architecture

Understand versioning, resource families, compatibility, and request IDs.

Responses & runs

Model interactive and long-running Starfire work programmatically.

Webhooks

Receive signed asynchronous events and inspect delivery attempts.