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

# API Access & Credentials

> Manage Starfire AI API keys, service accounts, scopes, and secure credential practices.

# API access & credentials

Developer workloads should use dedicated developer credentials rather than reusing a person's interactive Starfire browser session.

## API keys

An API key represents a programmatic identity and the permissions granted to an integration.

A key can be associated with concepts such as:

* display name
* environment
* permission scopes
* expiration
* rate-limit policy
* application or organization ownership

<Warning>
  Treat every API key as a secret. Keep it in server-side configuration or a secrets manager. Never place a real key in client-side JavaScript, mobile app bundles, screenshots, chat messages, or public repositories.
</Warning>

## Scopes

Scopes limit what a credential can do. The Starfire v1 developer architecture is designed around narrow permissions for resource families such as models, responses, runs, files, artifacts, research, builds, knowledge, and usage.

Use the smallest scope set that allows the integration to work.

A service that only starts FORGE builds and reads their resulting artifacts should not automatically receive access to unrelated account administration or organization settings.

## Key lifecycle

A production credential needs a lifecycle, not just a creation button.

Plan for:

* creation
* secure storage
* expiration where required
* rotation
* revocation
* ownership changes
* audit visibility

If a key is lost or may have been exposed, replace and revoke it rather than continuing to trust it.

## Live and test environments

Starfire's Developer Platform architecture is designed to distinguish production credentials from test or sandbox-style credentials as the developer environment expands.

Do not assume a test environment has identical billing, models, or external integrations to production unless the relevant developer documentation explicitly says so.

## Service accounts

Business and organization workloads should prefer service accounts or organization-owned applications when available. This avoids making a production integration depend on one employee's personal account.

## Organization ownership

An organization-owned credential can be governed by organization policy, usage limits, and billing context. Removing an employee should not require rebuilding the entire integration if ownership was modeled correctly from the start.

## Browser sessions are separate

Revoking a browser session does not automatically mean every independent API credential is revoked. Review both interactive and developer access when responding to an account-security issue.

<CardGroup cols={2}>
  <Card title="Applications & service accounts" icon="server" href="/developers/applications-service-accounts">
    Organize production integrations around durable ownership.
  </Card>

  <Card title="Rate limits & errors" icon="triangle-exclamation" href="/developers/rate-limits-errors">
    Build integrations that handle quotas and failures predictably.
  </Card>
</CardGroup>