​

API logs & usage

Developer workloads need operational visibility. The Developer Platform is designed to expose request and usage metadata so an integration can be debugged without giving developers Control Center access.

​

API logs

A developer log entry can include metadata such as:

• timestamp
• request identifier
• application or API key identity
• endpoint family
• status
• latency
• model when relevant
• token/usage metadata where available
• credits consumed
• associated run/build identifier
• error category

Sensitive request bodies should not be logged indiscriminately.

​

Request identifiers

The request identifier is the best reference when connecting an application error to Starfire’s server-side telemetry. Store it alongside your own application logs when possible.

​

Usage dashboard

Developer usage can be broken down by dimensions such as:

• hour, day, or month
• application
• credential
• endpoint family
• model
• status/error
• workload type

Relevant measures can include:

• requests
• tokens where applicable
• credits
• searches
• research runs
• builds
• artifacts
• errors
• latency

​

Shared metering, separate reporting

Developer API usage and web workspace usage can participate in the same underlying Starfire billing account while remaining separately visible for operational reporting. This helps an organization answer whether a usage spike came from people using the web app or an automated integration.

​

Privacy boundary

Operational logs should contain enough information to diagnose performance and errors without becoming a permanent copy of every user prompt or private file.

​

Control Center

Authorized platform administrators have broader operational views for diagnosing API abuse, provider failures, rate-limit events, and platform-wide developer health.