Authentication

Sending a key

Every Stawka request expects an Authorization header with a bearer token:

curl https://api.stawka.eu/rates \
  -H "Authorization: Bearer cp_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

For browser-friendly examples (e.g. embedded in the docs), the API also accepts the same value as a ?api_key= query parameter. Prefer the header in production — query strings end up in server access logs.

Key format

Keys are 51 characters total:

cp_live_<43 base64url chars>

• cp_live_ — environment prefix. cp_test_ is reserved for a future sandbox tier.
• The 43-char body is 32 bytes of cryptographic randomness, base64url encoded without padding.

Stawka stores only a SHA-256 hash of each key, plus the first 12 characters (cp_live_XXXX) so the dashboard can display a recognisable prefix in the key list. A lost or leaked key cannot be recovered — revoke it in the dashboard and mint a new one.

Revocation

Clicking Revoke in the dashboard:

1. Sets revoked_at on the key in the database. The row stays around for the audit trail.
2. Deletes the cached entry in our edge KV cache.

Worst case, a revoked key keeps working for up to 60 seconds while an in-flight cache-warm completes. The dashboard shows the cached-key TTL as guidance. If you suspect a leak that needs immediate cutoff, contact support; the same lever the dashboard pulls is also wired up behind a one-shot flush.

Missing or invalid keys

A request without a valid Authorization header (or ?api_key=) gets:

{ "error": "INVALID_KEY" }

with status 401. The same code covers missing, malformed, revoked, and unknown keys — the dashboard’s audit log distinguishes them, but the API surface deliberately does not, so an attacker can’t probe prefixes by status.