Authentication

API keys

Generate API keys use the format esk_ followed by a 16-character key id, an underscore, and a 43-character secret — for example esk_0123456789abcdef_…43_secret_characters…. You see the full key only once, at creation. Store it somewhere safe (a secrets manager or environment variable); there is no way to view it again later.

Keys are created, listed, and revoked on the API page of your dashboard. Creating API keys requires an active subscription.

Making authenticated requests

Include your API key on every request using either of two headers — both are accepted everywhere:

• Authorization: Bearer esk_… — standard bearer header (recommended)
• x-api-key: esk_… — simple key header

Pick one and use it consistently. The samples below show both.

# Option 1: Authorization header (recommended)
curl https://api.everythingstudios.ai/v1/balance \
  -H "Authorization: Bearer esk_YOUR_API_KEY"

# Option 2: x-api-key header
curl https://api.everythingstudios.ai/v1/balance \
  -H "x-api-key: esk_YOUR_API_KEY"

Test mode: try the API without an account

The public test key esk_testmode lets you exercise the full job flow with no account, subscription, or balance. Send it in either header exactly like a real key:

curl -X POST https://api.everythingstudios.ai/v1/jobs \
  -H "Authorization: Bearer esk_testmode" \
  -H "Content-Type: application/json" \
  -d '{"type":"text-to-3d-preview","input":{"prompt":"test"}}'

Jobs created with the test key succeed immediately and always return the same sample asset in model_urls.glb. They are free: no real inference runs, nothing is billed, and webhooks are never sent. All task types are accepted (text-to-3d-refine ignores preview_task_id).

Test jobs share one public workspace — use a unique idempotency_key per test run so concurrent runs don't collide. When you're ready for real generations, swap in a key from your dashboard.

Revoking keys

Revoke a key from the API page whenever it is no longer needed — for example when a key may have leaked, or an integration is being retired. Revocation takes effect immediately: every request is checked against the current key state, so a revoked key is rejected on the very next request.

Failed authentication

A missing, invalid, or revoked key results in a 403 Forbidden response. The denial happens at the API gateway before your request reaches application code, so the response body is the gateway's own {"message":"Forbidden"} — not the standard {"error": {"code": …}} envelope. Treat any 403 from the API as an authentication problem: check that your key is present, unmodified, and not revoked.

Key ownership and scoping

API keys are scoped to your account. You can only create jobs, and only read jobs, that belong to the account the key was issued for.

If you request a job id that belongs to another account, the API responds with 404 — never 403 — so the existence of other users' jobs is not leaked. A 404 on a job you believe you created usually means the job belongs to a different account (or the id is wrong), not that you lack permission for it.