> ## Documentation Index
> Fetch the complete documentation index at: https://aidocs.ethanbragdon.icu/llms.txt
> Use this file to discover all available pages before exploring further.

# 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:

```text theme={null}
models
chat / responses
runs
research
files
artifacts
builds
projects
knowledge
embeddings
usage
webhooks
```

<Warning>
  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.
</Warning>

## 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.

<CardGroup cols={2}>
  <Card title="Authentication & API keys" icon="key" href="/developers/api-access">
    Create and secure scoped developer credentials.
  </Card>

  <Card title="API architecture" icon="diagram-project" href="/developers/api-architecture">
    Understand versioning, resource families, compatibility, and request IDs.
  </Card>

  <Card title="Responses & runs" icon="play" href="/developers/responses-runs">
    Model interactive and long-running Starfire work programmatically.
  </Card>

  <Card title="Webhooks" icon="webhook" href="/developers/webhooks">
    Receive signed asynchronous events and inspect delivery attempts.
  </Card>
</CardGroup>