Authentication

Sending a key

Pass the key in the Authorization header:

curl -G https://api.zuse.live/v2/licenses \
  -H "Authorization: Bearer zuse_sk_..." \
  --data-urlencode "name=Jane Doe"

Keys start with zuse_sk_. The same key works for the REST API and the MCP server.

Creating and revoking keys

Keys are managed in the console.

• The full key is shown once, at creation. Zuse stores only a SHA-256 hash and cannot show it again.
• The console lists each key by name, a short prefix, and its last four characters, so a key can be recognized without being recoverable.
• Revoking is immediate. A revoked key is rejected on its next request and cannot be restored. Create a new one instead.

Use a separate key per environment or per integration. That way one can be rotated or revoked without touching the others, and usage is easier to attribute.

Failed authentication

A missing, malformed, or revoked key returns 401:

{
  "error": {
    "code": "unauthorized",
    "message": "Missing or invalid API key. Send 'Authorization: Bearer <key>'.",
    "request_id": "req_5f0c1e7a9b2d4c6e8a1b3d5f"
  }
}

The response includes a WWW-Authenticate: Bearer header.

What is checked, and when

The key is checked on every request, before anything else runs. In order:

1. The key exists and has not been revoked.
2. The account behind it is active.
3. The account is not restricted.
4. The request is inside the rate limits and the team's credit covers it.

Nothing is cached between requests, so revoking a key or deactivating an account takes effect on the very next call.

Only the header, only over TLS

• A key is read from the Authorization header and nowhere else. A key placed in the URL (?api_key=...) is ignored, because URLs end up in browser history, proxy logs and referrer headers.
• Call the API over https:// only. Responses carry Strict-Transport-Security.
• Wrong keys lock the address out. More than 10 wrong keys from one address in a minute blocks that address for 15 minutes (429, code address_locked). A missing key does not count; a wrong one does.

Keeping keys safe

• Keep keys on the server. Do not ship them in browser or mobile code.
• Load them from environment variables or a secrets manager, not source control.
• When contacting support, share the key prefix only, never the full key.

Teams

Every account starts in a personal team. Create a team in the console to share keys and one view of usage with other people.

• Everyone on a team sees the team's keys. Owners and admins can revoke any of them; members can revoke their own.
• A key's calls are charged to the team it was created in. Everyone on the team draws on one balance: see Pricing and metering.
• Removing someone from a team revokes the keys they created in it.