Resource Identifier Reference

Understand how Starfire AI resource identifiers are used across support, APIs, builds, artifacts, billing, and diagnostics.

Resource identifier reference

Starfire uses stable resource identifiers so a user, developer, and administrator can refer to the same object without relying on display names.

Common identifier families

The exact prefix format can evolve, but Starfire resources are conceptually identified separately by type.

Resource	Example form	Used for
Request	req_…	One API or platform request
Run	run_…	Long-running execution
Build	build_…	FORGE build job
Artifact	artifact_…	Durable workflow output
File	file_…	Uploaded or stored file
Project	project_…	Persistent project workspace
Knowledge base	kb_…	Indexed Knowledge collection
Organization	org_…	Team ownership/policy boundary
Application	app_…	Developer application
Webhook event	evt_…	One asynchronous event
Billing account	billing_…	Personal or organization billing context

These examples document the resource model, not a guarantee that every current Alpha deployment uses the exact same public prefix for every object.

Why IDs matter

Display names can change. IDs are the stronger reference when:

• opening a support case
• searching Control Center
• correlating API logs
• investigating a build or research run
• identifying an artifact
• reconciling billing
• debugging a webhook delivery

Request IDs

A request ID is especially useful because it connects a visible error with server-side telemetry. When Starfire surfaces a request ID, include it with the timestamp when asking for technical support.

IDs are not credentials

A resource identifier usually identifies an object; it does not authorize access to it. Starfire still checks account, organization, project, scope, or administrator permission before returning protected data.

Never confuse a resource ID with an API key, reset token, session token, webhook secret, or other credential. Credentials should not be posted into support notes or public documentation.