uttapen

API privacy: what uttapen stores and what it never logs

The API path never stores prompts or responses. Exactly which metadata is kept, the dashboard chat exception, and how traffic reaches the provider.

Updated: September 7, 2026

This page is our technical commitment, not a legal document. The legal text lives in the privacy policy and the terms of use; if the two ever disagree, the legal text wins. Here we say precisely what is recorded on the API path and what is not.

What is not stored

Prompt and response content on the API path is never stored. Not in the database, not in logs, not in a cache. The gateway reads the request body to learn the model, the parameters and the approximate size, forwards it to the provider, relays the response to you as it arrives, and once the request ends no copy of the content remains in memory or on disk. That includes images, files, tool call arguments and reasoning text.

Server logs are structured and contain only the fields listed below. If we ever need the content of a request to debug something, you have to send it to us yourself — we cannot recover it.

What is stored (metadata)

One row per request is recorded with these fields, and shown back to you in dashboard → usage:

FieldWhy
Request id (X-Uttapen-Request-Id)Error tracing and matching against the wallet
User id and key idBilling and monthly caps
Model, endpoint, whether it streamedUsage reporting
Input, output, reasoning and cached token countsBilling
Held amount, final amount in toman, state (held, settled, released, reconciling)Billing
Start time, time to first byte, durationService quality
Error code, if anyDebugging
Client IPAbuse prevention
Provider-side generation idReconciling usage after a disconnect

These rows are tied to the wallet and the ledger and are kept so that any invoice can be defended. Deleting your account detaches the rows from your identity, but the amounts stay in the ledger (an accounting requirement).

Exception: the dashboard chat

The dashboard chat and the playground are side tools for trying models out. In both, the conversation history is your own data and is stored so you can come back to it; the same goes for files you upload in chat. You can delete any conversation individually, and deleting your account wipes every conversation and file. To title a conversation automatically, its first message is sent to a cheap model; the output is stored only as the conversation title.

If you do not want any content stored, use the API rather than the chat.

The traffic path

Your request reaches the uttapen server in Iran over TLS. The gateway swaps your key for our own account key at the provider, strips the headers that identify you (IP, cookies, X-Forwarded-*) and sends the request to the provider through a stateless relay outside Iran. The relay only passes traffic through: no data, no keys and no content logs live on it. The provider sees the request coming from the relay's IP, not yours, and knows nothing about your identity. The response comes back along the same path. This path adds roughly 100 milliseconds of latency.

The result: from the provider's point of view, all uttapen users are a single customer. From your point of view, uttapen neither sees nor keeps your content.

The destination provider's policy

Request content does reach the model provider (OpenAI, Anthropic, Google and others, through an aggregator) and their data retention policy applies to it. For API traffic the large providers generally do not use content for training and delete it after a short abuse-prevention window, but that is their commitment, not ours. For sensitive data:

  • Strip or pseudonymize personally identifying information (names, national ID numbers, phone numbers) before sending, and put it back after the response.
  • Prefer providers with an explicit retention policy; each model page names its provider.
  • For organizations under a legal requirement, open-weight models on your own infrastructure are the right answer — not any cloud API.

Keys and accounts

  • API keys are stored only as a hash; not even we can see the full key.
  • Your mobile number is used for sign-in and account notifications (top-up receipts, low-balance alerts); it is never given to a provider or a third party.
  • Payments go through Zibal; card details never reach our servers.
  • Account deletion is done through support: identity data, keys, conversations and files are deleted, and only the de-identified accounting rows remain.