The security model, plainly.
TmpState removes credentials instead of managing them. This page explains what protects your data, what the trade-offs are, and what we deliberately cannot do.
Capability URLs, not credentials
Every database is addressed by an unguessable URL: a capability with roughly 155 bits of entropy (30 characters over a 36-symbol alphabet). That is the same trust model as a private share link, and the same order of strength as a strong password.
There are no API keys to provision, rotate, or leak into repositories - which also means there is no key-management console to misconfigure. Whoever holds the URL holds the database; treat it like a password and keep it server-side.
Hashed at rest
TmpState stores only the SHA-256 hash of each capability and of each Pro account token - never the raw value. If our datastore were ever dumped, it would contain no usable database URLs and no usable account tokens.
The flip side is deliberate: we cannot look your URL up for you. The creation response is the one moment the raw capability exists; persisting it is the client's job, and our docs tell agents exactly where to put it.
Rate limits and input hardening
Every endpoint is rate-limited per client IP - database creation, reads, writes, and the expensive full-database scans most of all. Bursts get a 429, not a bill.
Request bodies must be JSON objects; the keys __proto__, constructor, and prototype are rejected at any depth; document and collection names follow strict patterns; and document size limits are enforced on the merged result of every PATCH.
Expiry enforced on every request
A free database lives 24 hours. Expiry is checked on every single request - not by a background job that might lag - so an expired database returns 410 immediately, everywhere.
Expired data stays frozen and restorable for 72 hours, then a daily job deletes it permanently. Temporary means temporary, on a schedule you can read in the docs.
You can always delete, instantly
DELETE with ?confirm=true destroys a database and its documents immediately - it works even after expiry, costs nothing, and needs no support ticket. If a URL leaks, this is the kill switch.
Deletes are never rate-limited by quotas: a full database can always be emptied.
Payments stay with Stripe
All payments - one-time extensions and Pro subscriptions - run on Stripe Checkout. Card numbers never touch TmpState servers, webhooks are signature-verified, and fulfillment is idempotent so a replayed event can never double-apply.
Billing changes are disclosure-first: any charge beyond what you already agreed to requires an explicit, priced acknowledgment in the request before anything is created or billed.
What TmpState is not for
Do not store regulated or highly sensitive data (payment card data, health records, government identifiers) in a TmpState database. The capability model is honest and strong for prototypes, agent workflows, demos, and internal tools - but a bearer URL is a bearer URL: anyone who obtains it can read and write that database. Product apps should keep the URL server-side and expose their own API routes, exactly as the agent docs and database skill instruct.
Found a vulnerability? Email support@tmpstate.dev - reports are read by a human and answered.