Authentication

API keys, scoping, rotation, and revocation.

Every request carries an org API key in the standard header:

Authorization: Bearer sk-dyno-XXXX

Keys are per-org, not per-app. One org has a single persistent endpoint (https://<your-org>.dynoyard.app/v1) and as many keys as you want — prod, staging, cursor, per-customer, etc. All keys see the same model catalog.

Create a key

Dashboard → Keys → New key. Name it, optionally restrict which models it can call (defaults to your org’s full enabled set), then create. The next screen shows the sk-dyno-XXXX token exactly once — copy it then; we store only a hash.

Storage

We persist only a SHA-256 hash of the token; the plaintext never lands in our database. Incoming Bearer tokens are validated against the hash, then the request is forwarded to the upstream model with an internal provider key — your sk-dyno key never reaches the upstream model process.

Per-key restrictions

• Allowed models — scope a key to a subset of the org’s enabled models. A key can only narrow the org set, never widen it.
• Monthly spend cap (coming soon) — hard USD ceiling per key; returns 429 past the threshold.

Rotation & revocation

Rotate or revoke from the Keys page. The old key starts returning 401 unauthorized within seconds. Rotation mints a new sk-dyno-XXXX (shown once) and invalidates the previous value.

Management keys

Org-admin tasks (checking credits, programmatic key management) use a separate key class minted on Settings — sk-dyno-mgmt-XXXX — against the management host https://api.dynoyard.app/v1/management. Management keys can’t authorize inference; inference keys can’t authorize management calls. See the API contract.

Programmatic / CI use

Use a regular sk-dyno-XXXX inference key from CI or scripts — mint a dedicated named key per environment so you can rotate or revoke it independently.