DocsKeys, origins and quotas4 min read

Keys, origins and quotas

The threat model is blunt: any key that reaches a device is public. Everything below follows from that sentence.

  • We keep only a one-way hash of a key, never the key itself. A stolen database dump does not hand over working keys, and support cannot read yours back — regenerate instead.
  • The key is shown once, at creation. Nothing in the dashboard ever prints it again.
  • live and test are not a hint. A test key is refused on a project whose type says production, and never bills real characters.
  • Keys are per project, so one app leaking its key does not expose your other apps — and revoking one does not silence the others.

Allowed domains

Leave the list empty and any Origin is accepted — right for a Node server, wrong for a browser app. List the exact origins you ship to, and a copied key stops working on every other host: the service compares the Origin header against that list and answers 403 origin_not_allowed.

What a quota protects

  • Characters are counted on the source text, once per new string. Approved strings replay from cache for free, so a stable UI stops costing anything.
  • Requests per minute is enforced per key. The SDK stops itself on a 429 for the rest of the session rather than hammering.
  • If the meter runs out you get 402 with usage in the body — not a silent degrade. Your app keeps rendering source text; the developer gets told.

Rotating a leaked key

  1. 1API Keys → revoke the exposed one. It dies immediately, in cache and out.
  2. 2Mint a replacement, ship it, and treat the old string as a public secret for the rest of its life — it is in your git history and in someone's logs.
  3. 3Add the origin list before the next release, not after.