Authentication
One header on every metered request:
KC-APIKey: kc_live_…No Authorization: Bearer, and never a query parameter. A key in a URL is written to browser history, to intermediate proxy logs and to the Referer of whatever the page links to next.
Two kinds of key
Every key is either a server key or a browser key, chosen when you issue it. This is not a label — the two are enforced differently, and picking the wrong one fails loudly rather than quietly.
Server keys (the default)
Backend-only. A request carrying an Origin header — which is to say, a request from a browser — is rejected with 403, even though the key itself is valid.
That is deliberate. Pasting a server key into frontend JavaScript ships your secret to every visitor, and the failure would otherwise be invisible: the code works, and the key is public. Instead it stops working the moment it reaches a browser, which is a bug you find in five minutes rather than in a billing statement.
Browser keys
For calling the API directly from your own site. A browser key must be issued with at least one allowed origin — issuing one with an empty list is refused, because a browser key with no origins is just a public secret.
Only the origins you list may use it from a browser. A leaked browser key is worth nothing on any other site, and we send CORS headers to your registered origins so the call works from your frontend without a proxy.
Origins are stored canonically as scheme://host[:port]. You can paste app.example.com and we will standardise it to https://app.example.com; for local development type the scheme and port explicitly (http://localhost:3000). Paths and wildcards are rejected.
Browser keys are available on paid plans. On Free, issue a server key and call the API from your backend.
Choosing
| Where the call is made | Key type |
|---|---|
| Your backend, a cron job, a script, a notebook | Server |
| Your website’s JavaScript, a browser extension | Browser, with your origins listed |
| A mobile app | Server, called through your own backend — an app binary is not a secret store |
Rotating a key
Issue the new key first, deploy it, then revoke the old one. Revocation takes effect within about a minute; keys are cached briefly on our side to keep the hot path off the database.
Changing your account password does not revoke your API keys. A password change ends your portal sessions and nothing else — /v1 resolves a key against that key’s own status and never looks at your password. If you are recovering from a compromise, revoke the keys explicitly from API keys.
What is not authenticated
Five routes take no key at all. GET /v1/plans, GET /v1/pricing/units and GET /v1/stats are the pricing table and the corpus size — both things we publish anyway. GET /v1/chains and GET /v1/protocols are metadata: which chains and protocols are servable, which you need in order to build a valid request in the first place.
They are unmetered as well as unauthenticated, so they cost nothing against your quota and do not appear in your usage. Everything under /v1/positions and /v1/pools requires the header and is metered.