The core commitment
TokenGate stores the instructions a software team publishes. It does not store end-user request content or AI responses.
Conversation content is handled in memory long enough to route the request and return the answer. It is not written to TokenGate's client, usage, or authorization-cache records.
Request lifecycle
What happens at the gate
Receives
A project access key, a random installation UUID, the end-user request, and any media the app includes.
Checks
The installation UUID is validated and converted into a keyed fingerprint. The applicable usage allowance is checked before provider execution.
Forwards
Published instructions and request content go to the AI provider chosen by the app publisher. Selected fields may also go to the publisher's authorization service when configured.
Keeps
Token counts, model and prompt references, cost estimates, timestamps, authorization status, and the project-scoped installation fingerprint.
Storage receipt
Kept and not persisted
TokenGate keeps
- Published instructions and immutable versions
- Provider keys, encrypted with an organization data key
- A keyed, project-scoped installation fingerprint
- Token counts, request time, model, prompt, and auth result
- Estimated or provider-reported cost metadata
TokenGate does not persist
- End-user request text, images, audio, video, or files
- AI-provider answers
- The raw installation UUID
- Authorization headers or provider credentials in logs
- Arbitrary response bodies from authorization services
Installation identity
An allowance without a user account
What an app sends
TokenGate requires a random UUID v4 in X-Installation-Id. Email addresses, usernames, phone numbers, and customer database IDs do not satisfy this identity contract.
What survives
When the app publisher stores the UUID correctly, an ordinary in-place update keeps it and its allowance. Uninstalling the app or clearing its storage creates a new installation and therefore a new allowance.
What TokenGate stores
Before persistence, TokenGate applies a secret-keyed function scoped to the customer's project. The resulting pseudonymous fingerprint cannot be used to match an installation across projects.
Retention and deletion
Short detail, longer totals
Detailed usage events and inactive installation fingerprints without a block or custom quota.
Monthly app-level totals that contain no installation fingerprint.
Routine reverse-proxy access logging is disabled. Incident logs, when needed, exclude content, credentials, installation IDs, and URL parameters.
An end user asks the app publisher to erase an installation. The publisher can use TokenGate's authenticated dashboard or developer tools to delete its detailed usage and custom quota. If the installation is explicitly blocked for abuse, only the deny fingerprint remains until the publisher removes the block or deletes the project.
Responsibility boundary
TokenGate is one part of the data path
The app publisher decides what its app collects, which AI provider it uses, and what content it sends. That provider processes each request under its own data policy. TokenGate's non-retention practice does not certify the publisher's whole app.
For application traffic, the publisher acts as controller or business and TokenGate acts as processor or service provider. TokenGate separately manages its own account, billing, fraud-prevention, and service-security data.
TokenGate is intended for ordinary consumer and wellness apps. It does not offer HIPAA, medical, biometric, financial-compliance, or children's-data commitments. Do not use it for regulated data that requires those contracts and controls.
For app publishers
Give users a page they can verify.
Link here without implying that TokenGate certifies your entire app.