TTL and retrievals
Every kubbi is temporary by design. Two lifecycle controls determine when the payload becomes unavailable.
TTL
ttl_seconds sets how long the kubbi lives. The minimum is 60 seconds. The maximum depends on your plan tier.
After the TTL elapses, the payload is wiped server-side. Claim attempts return 410 Gone.
Retrieval limits
max_retrievals sets how many times the payload can be claimed. Omit it (or set null) for unlimited within TTL. Setting it to 1 implements burn-after-read semantics.
Burn enforcement happens server-side, not as a client flag. Attempting to claim past the limit returns 410 Gone with error: "gone" and a message noting the kubbi has reached its maximum retrieval count.
Inspect doesn't count
GET /r/:token/inspect returns metadata only and does not count toward the retrieval limit. The plain GET /r/:token is also a non-consuming inspect (it adds a claim object pointing at the claim URL). Use either to verify a kubbi before consuming it.
Early delete
The producer can wipe a kubbi early via DELETE /api/v1/kubbis/:id. The encrypted payload is destroyed immediately and subsequent claims return 410 Gone.
Terminal states
A kubbi reaches one of three terminal states. The payload is wiped at each:
- expired: TTL elapsed
- burned:
max_retrievalsreached - deleted: producer deleted it early
Once wiped, the content is unrecoverable. For details on the encryption posture see encryption and storage; for the full security model see Security & Operations.