Authentication

Every request to the gateway carries a Twotic key. The same key works across every API in the catalogue — subscribing to a new API never means a new credential.

Sending the key

Two forms are accepted, and they are equivalent:

# Preferred
curl "https://www.twotic.dev/v1/token-counter/models" \
  -H "Authorization: Bearer $TWOTIC_KEY"

# Equivalent, for clients that reserve Authorization
curl "https://www.twotic.dev/v1/token-counter/models" \
  -H "X-Twotic-Key: $TWOTIC_KEY"

How keys are stored

Only a SHA-256 hash of your key is stored, along with the first few characters so the dashboard can identify it. A database compromise does not yield usable keys — and neither does a support request, which is why we genuinely cannot recover a lost key for you.

Rotating a key

Keys are additive, so rotation needs no downtime:

1. Create a second key in the dashboard.
2. Deploy it to your application.
3. Confirm traffic has moved — the key list shows a last-used timestamp for each.
4. Revoke the old key.

Revocation takes effect on the next request. A revoked key is rejected exactly like one that never existed, so an attacker learns nothing from the difference.

Keeping keys out of the browser

A Twotic key spends real credit, so it belongs on a server. Calling the gateway from client-side JavaScript exposes the key to anyone who opens devtools. Put a thin route in your own backend, keep the key there, and let your frontend call that.

One key, every API

The same key works across the whole catalogue. Subscribing to a new API never means a new credential to store, rotate or leak — which is the main reason integrating a second API here costs almost nothing.