Documentation Index
Fetch the complete documentation index at: https://mayatech.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
API keys
All requests authenticate via theX-Api-Key header. Keys look like al_live_<64-hex>:
al_live_8jKpQ4); the platform stores a one-way hash, so we cannot recover the plaintext for you.
Older keys may begin with
og_ (legacy OnlyGold prefix). They continue to work — the prefix has no effect on validation. We recommend rotating to al_live_* at your convenience.Authorization: Bearer <key> form is also accepted as an alias, but X-Api-Key is the documented contract — pick one and stay consistent.
Scopes
Every key has one of three scopes. Pick the narrowest scope that meets your integration’s needs.| Scope | Allows |
|---|---|
read | All GET requests (loras, balance, team, usage, generation status, pricing) |
write | All read access plus POST /v1/images, POST /v1/videos, POST /v1/files, POST /v1/webhook_endpoints, and per-resource cancel / test / rotate_secret |
full | All operations including reading and rotating other API keys via the dashboard |
403 missing_scope. Most integrations only need write — reserve full for management tooling.
Rotation — the 24h grace window
Rotate fromSettings → API keys → Rotate. The platform mints a new key (returned once) and atomically marks the old key with deactivate_at = now() + 24h. Both keys validate during the grace window so deployments can roll without downtime; after 24h, the old key starts returning 401 invalid_api_key automatically — no manual revoke required.
Workflow:
- Click Rotate in the dashboard. Copy the new plaintext immediately.
- Roll the new key through your secret store and redeploy.
- Wait out the 24h grace window — your old deploys keep working until they’re replaced.
- After 24h the old key auto-deactivates. No further action.
401 invalid_api_key within seconds.
Per-team rate limits
Rate limits are per-team — multiple keys on the same team share the bucket. Burst capacity is 120 forPOST /v1/images / POST /v1/videos and 1200 for reads, with sustained rates of 60/min and 600/min respectively. See Rate limits for the full table and 429 recovery contract.
Versioning
Pin a contract version with theAurous-Version: YYYY-MM-DD request header so deploys downstream of yours can’t break you. Every response echoes the applied version in the Aurous-Version response header. Without the request header, we use your team’s default_api_version (set at signup). See the Changelog for what each date-pin contains.
Security checklist
- Never embed an API key in client-side bundles, mobile apps, or browser-side JS — proxy via your own backend.
- Never check a key into git, even on a private repo. Use a secret manager (Doppler, 1Password, AWS Secrets Manager, etc.).
- Never pass the key in a URL query string — query strings get logged by intermediate proxies and CDNs. Always use the
X-Api-Keyheader. The platform refuses query-string keys explicitly. - Treat the key like a password — anyone with the plaintext can spend your team’s credits.
- Tighten the scope on production keys to
write(orreadfor read-only integrations) so a leak can’t escalate to key management. - Rotate quarterly as a hygiene baseline; rotate immediately if you suspect any compromise.
Error responses
| Status | Code | When |
|---|---|---|
401 | missing_api_key | X-Api-Key header is absent. |
401 | invalid_api_key | Key is unknown, revoked, or past its 24h deactivate_at. |
403 | missing_scope | Key authenticated but its scope doesn’t permit the route. |
request_id workflow for support.