Privacy and compliance · 2026-09-25
Reading the data flow between EVREN and LLMTR
The three stops of an EVREN call made through LLMTR: your application, LLMTR and EVREN. Which key, which content and which records exist at each stop, and how the answer comes back.
Short answer
An EVREN call made through LLMTR passes three stops: your application, which prepares the request; LLMTR, which authenticates and forwards it; and EVREN, which runs the model. Each stop sees different things and keeps different things. A privacy assessment starts by reading each stop separately rather than treating the three as one box.
We recommend using EVREN through LLMTR: you register your own EVREN key once in Settings, and the same code then reaches both EVREN models and the rest of the catalog. The key stays yours, and EVREN's own logging and retention policy still applies unchanged.
First stop: your application
The request takes shape in your code first. The system instruction, earlier messages, attached files and a tool's result are added to the user's message here. This is the only place where it is decided what goes to EVREN; later stops carry the content, they do not change it.
The request's authentication header carries your LLMTR API key. No EVREN key appears at this stop. As long as the key sits on the server in an environment variable, the user's browser or mobile app never sees a key at all.
Removing or pseudonymising personal data also happens at this stop. The next two stops carry the request as it is, so anything not removed here reaches EVREN. Your own error tracking and analytics tools are part of this stop too: whether request and response text is written there is your decision.
Second stop: LLMTR
LLMTR first authenticates your LLMTR key, recognises that the model identifier is an EVREN row, and finds the EVREN key registered in your Settings. The request is forwarded to EVREN with that key. If no key is registered, the request never goes to EVREN and returns 403 provider_credential_required.
Request and response bodies are not written to the database at this stop. The usage log records the model, token counts, message count, cost, status code and duration; on EVREN rows the cost is $0. Your EVREN key is stored encrypted and used only for requests bound for EVREN. LLMTR applies no rate limit of its own to these rows, so a 429 on an EVREN row always comes from EVREN's own limit and returns with the type provider_rate_limited.
Third stop: EVREN
The request reaches EVREN on your key, so from EVREN's point of view the requester is you and your e-Devlet-verified account. Inference runs on EVREN's infrastructure hosted in Turkey, and EVREN's terms of use apply. When the terms change materially EVREN asks for acceptance again; that is done from your EVREN account, not from LLMTR.
EVREN's schema shows two things: a content moderation layer runs on generative endpoints, and a record of execution and billing state is kept for each request. How long content is kept, and for what purpose, is not written in any public source.
Stop by stop
The table shows the same request at all three stops. Cells marked "unknown" are where no public source exists.
The first row is the one most often overlooked: an application that writes request and response text to its own server logs or error tracker has kept a content record itself, before LLMTR or EVREN.
| Stop | Sees | Keeps |
|---|---|---|
| Your application | Full request and answer, LLMTR key | Your decision |
| LLMTR | Full request and answer, registered EVREN key | Model, tokens, cost, status code, duration; no content |
| EVREN | Full request and answer, EVREN key and linked account | Request-status record and quota; unknown for content |
The answer's return and errors
The answer comes back along the same path. Even when stream: true is sent, on these rows the answer is completed first and then delivered in chunks; the first chunk arrives when generation has finished. This affects waiting time, not content.
When EVREN rejects a request, the provider's error text is not passed on; the status code and the error.details.upstreamStatus field are. 4xx codes are kept as they are, and 5xx faults on EVREN's side come back as 502. Whether to retry a request is therefore decided from the code in upstreamStatus, not from an error text.
Frequently asked questions
Should I use EVREN directly or through LLMTR?
We recommend using EVREN through LLMTR. Your requests still go to EVREN on your own EVREN key and LLMTR charges nothing for them; the difference is that the same code also reaches the other models in the catalog. EVREN's logging and retention policy is not affected by the choice.
Does routing through LLMTR change EVREN's data policy?
No. The request reaches EVREN on your key and EVREN's terms of use apply unchanged. LLMTR is responsible only for what it keeps on its own side.
Does my registered EVREN key go to any other provider?
No. The key is used only to send requests bound for EVREN rows. Requests to other models in the catalog never carry the EVREN key.
In which country does the model run?
On EVREN rows inference runs on EVREN's infrastructure hosted in Turkey. The catalog marks these rows with a Turkey-hosted badge.
Why can I not see EVREN's error message?
The provider's error text is not forwarded; the response carries the status code and EVREN's original code in error.details.upstreamStatus. The error-handling article in this series explains what each code means.