A one-time code is one of the shortest-lived pieces of data you will ever handle. It exists to get you through a single door, once, and after that it is worthless. So why do so many tools treat it like something worth keeping? OTPBase takes the opposite view: a code's useful life is measured in minutes, and everything after that is liability, not a feature.
The lifecycle of a code
When a code arrives, it starts a clock it cannot stop.
| Phase | What happens |
|---|---|
| 0–15 minutes | The code is visible on your page and available through the read API. |
| After 15 minutes | The code is hidden from view. |
| Within 1 hour | The database row is physically deleted from disk. |
| After deletion | No backup retains it. It is gone. |
There is no archive, no "recently used codes," no quiet copy sitting in a backup snapshot for ninety days. The fifteen-minute visibility window matches how you actually use a code — you read it, you type it, you move on. The one-hour deletion is the part that matters for everyone who isn't you.
A clock, not a promise
Plenty of services will tell you they "never store your data longer than needed." That is a promise, and a promise is only as good as the company keeping it, its retention policy, its backup rotation, and whatever a future acquirer decides to do with the data.
OTPBase replaces the promise with mechanics. The row is deleted from disk within the hour because that is what the system does, not because someone remembered to honor a policy. There is nothing to subpoena after the fact, nothing to leak in a breach, nothing to hand over, because the data no longer exists. "Deleted" should be a state of the disk, not a line in a privacy page.
A relay, not a vault
This is the distinction that explains the whole design. A vault is built to retain: it holds your secrets indefinitely and its core promise is that they will still be there when you come back. A relay is built to pass things through and let go.
OTPBase is a relay. A code comes in from your paired phone or a self-hosted TOTP, lands on one page and the read API, and is then forgotten. We never want to be the place where a year of your verification codes — and the timeline of every account you logged into — sits waiting to be stolen. The safest data store is the one that is empty most of the time.
What burn-after-reading and E2EE add
Two options let you tighten the window further.
Burn-after-reading drops a code roughly thirty seconds after you copy it. If you only needed it once — which is the normal case — it disappears the moment its job is done, well before the fifteen-minute mark.
Optional view password turns on client-side end-to-end encryption. Codes are already encrypted at rest with AES-256-GCM, but with a view password the decryption happens only in your browser. The server holds ciphertext it cannot read. Combined with the deletion clock, that means a short-lived secret the server can't read while it has it, and doesn't have at all an hour later.
And there is zero telemetry around any of this — no analytics layer quietly recording which services you receive codes for.
The honest tradeoff
This design costs you something real: there is no history to scroll back through. You cannot look up the code you got last Tuesday, because it stopped existing within the hour. If you want an audit trail of every login, OTPBase is the wrong tool.
But that is the point, not an oversight. The absence of history is the same property that means there is nothing to breach, nothing to subpoena, and nothing to regret. A one-time code is transient by nature. The most honest thing a tool can do is treat it that way.