SaaS APIs
The public API beside your product, with test mode, per-customer keys and limits, without a gateway to run.
A SaaS vendor adding a public API needs the same five things every time: keys per customer, a way for those customers to try it without touching real data, limits per plan, safe retries, and enough usage data to answer a support ticket. Keyring is those five as one middleware and one dashboard, and it never sits in front of your infrastructure.
Shape
- One project per API you expose.
- One tenant per customer account, with your own account id as the tenant's
external_id, so a lookup from your side never needs a mapping table. - Keys minted per tenant, in test and in live, with scopes named after your permission model.
- Project defaults for rate limits, and per-key overrides for the plan a customer is on.
Test mode without a second deployment
The single-endpoint shape is what the docs lead with: one deployment serves kr_test_ and kr_live_ keys, and resources hands each handler the right database, queue or third-party client for the calling key's environment. Code far from the request, a receipt sender, a webhook dispatcher, reads currentEnv() from the ambient scope rather than a parameter threaded through six frames. Test mode has the details.
Rotation your customers can do
Rotation mints a successor and keeps the old key working for an overlap you choose, up to 7 days, so a customer with a fleet can roll it without a synchronised restart. Idempotency records are scoped per tenant, so a retry that lands on the new key during the overlap is still deduplicated. The embeddable component puts rotate, revoke and create inside your own settings page.
Answering the support ticket
Every key's page has requests and errors per day, and every tenant's page has request counts per project and environment per month. A denied request is logged in the environment of the key that was refused, so "my test key is rejected" is in the test-mode data. There is no per-request explorer yet; the request logs page says exactly what is there.
What you do not run
No gateway, no sidecar, no proxy. The middleware is 40 to 80 lines over the SDK, the SDK verifies from memory, and the control plane's outage is not yours: every node keeps verifying from its cache, and what happens to unknown keys during one is a decision you make per route.