Glossary
The vocabulary of keeping keys off the client.
The terms that show up across the docs and comparisons, defined in one place.
- API key exposure
- The failure Perishable exists to prevent: a secret upstream key (e.g. sk-…) shipped inside a browser bundle, mobile binary, or desktop app, where a stranger can extract and abuse it.
- Browser fingerprint
- A stable identifier derived from browser characteristics. Perishable binds each session JWT to a fingerprint so a token copied to a different browser is rejected.
- Entropy collection
- The client SDK gathering real input signals before it is allowed to mint a session. It raises the cost of headless automation that sits at document.ready with nothing to offer.
- JWT session
- A short-lived JSON Web Token the proxy issues after the entropy and fingerprint checks pass. It is what the client presents on subsequent calls instead of the real key.
- Session refresh
- The client SDK renewing its JWT before expiry, tuned by sessionOptions.expiryBuffer, so calls keep working while any leaked token still rots on schedule.
- Per-fingerprint rate limiting
- Configurable points-per-window (with optional block duration) keyed to the client fingerprint, so a single abuser cannot run up an unbounded bill.
- OpenAI-compatible
- Speaking the OpenAI HTTP request and response shape. Perishable proxies any provider that does — OpenAI, Anthropic via a compatible base URL, OpenRouter, Ollama.
- Upstream / base URL
- The real API the proxy forwards to. OPENAI_BASE_URL redirects the upstream from OpenAI to another OpenAI-compatible endpoint; the upstream key is attached server-side.
- Self-hosted proxy
- The Perishable process you run yourself — via npx perishable-proxy or an embedded PerishableServer — rather than a hosted gateway. Traffic stays on your infrastructure.
- Bot-resistance
- Raising the cost of casual, high-volume abuse without claiming to stop a determined attacker. Perishable is bot-resistant, not bot-proof.