EVREN API errors: choosing the right remedy

Short answer

An error on an EVREN row can come from two places. LLMTR's own errors, such as an invalid or revoked LLMTR key, are fixed on the LLMTR side. Errors from EVREN are passed on with types prefixed provider_, and because both the key and the account are yours, most of them are fixed on your EVREN account. The error type points straight to where the fix is.

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.

• LLMTR documentation: EVREN

Error types and where they are fixed

The table shows the errors an EVREN row can return and where each one is handled. The error.type field is the same in every case; the HTTP status changes with the type of error.

• LLMTR documentation: EVREN

Three separate 403s

provider_credential_required means no EVREN key is registered in LLMTR; the request never went to EVREN. provider_credential_rejected shows that EVREN did not accept the key: it may have been revoked or copied wrongly, or EVREN's terms of use may not have been accepted. This error covers both cases, so the terms acceptance is checked alongside the key.

provider_account_limited shows that EVREN refused the request on your account rather than on the key. The quota and credit state is read from EVREN's /v1/quota endpoint. This error is deliberately 403 and not 402: on LLMTR a 402 means your LLMTR balance is empty. EVREN rows are free, so this error has nothing to do with your balance, and topping up credit does not fix it.

• Source: EVREN OpenAPI schema (checked 25 September 2026)

upstreamStatus and retries

The error.details.upstreamStatus field always carries the original code EVREN returned, even when the HTTP status is 502. 4xx codes are kept as they are, and 5xx faults on EVREN's side are folded into 502. The provider's error text is not passed on, so the decision is made from the code, not from a message.

429 and 502 are situations that can pass with time and can be retried at growing intervals. 403s and other 4xx responses do not change on retry. In team or customer applications, key and account errors are not things the end user can fix; showing the user a general message and notifying the account owner brings the problem to the person who can solve it. The example below makes that split.

Retrying and notifying by error type

import time
from openai import OpenAI, APIStatusError

RETRYABLE = {429, 502}

def call(client: OpenAI, **kwargs):
    for attempt in range(3):
        try:
            return client.chat.completions.create(**kwargs)
        except APIStatusError as e:
            body = e.body if isinstance(e.body, dict) else {}
            error = body.get("error", body)
            kind = error.get("type")
            upstream = (error.get("details") or {}).get("upstreamStatus")
            if kind in ("provider_credential_required", "provider_credential_rejected",
                        "provider_account_limited"):
                # Not something the end user can fix: the account owner is notified.
                notify_owner(kind, upstream)
                raise
            if e.status_code in RETRYABLE and attempt < 2:
                time.sleep(5 * (attempt + 1))
                continue
            raise

Problems that do not come back as errors

Not every problem arrives with an error code. Because tool calling is not offered on the rows other than MiMo V2.6 Pro and DeepSeek V4.1 Flash TR, when a tool definition is added to a request for one of them the model may answer in plain prose instead of failing; the response is 200, but the expected tool call is missing. JSON mode is not offered on those rows either, so the required format is described in the instruction and whether the answer follows it is checked on your side.

An answer cut at max_tokens is not an error either; it shows as a finish_reason of length. When EVREN's own output limit is exceeded, however, the request is refused and comes back as one of the provider_upstream_error rows in the table.

Fields worth keeping in an error log

A few fields in your own application log are enough to tell a one-off error from a recurring problem: the time, the model identifier, the HTTP status, error.type, upstreamStatus and the label of the LLMTR key that sent the request. 429s clustering at the same hours point to a rate limit; 403s repeating on every request point to a key or account problem.

Request and response text does not need to go into this log. Errors can be classified without it, and the log does not turn into the kind of content record described in this series' privacy articles.

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.

Why can I not see EVREN's error message?

The provider's error text is not passed on. The response carries error.type and error.details.upstreamStatus; upstreamStatus is the original code EVREN returned.

Why is provider_account_limited not a 402?

On LLMTR a 402 means your LLMTR balance is empty. EVREN rows are free, so this error has nothing to do with the balance; returning it as 403 shows that the fix is on your EVREN account.

Can LLMTR support fix a problem on my EVREN account?

The EVREN account and key are yours; LLMTR cannot see or change your account. The fix for key and account errors prefixed provider_ is on EVREN's side. For problems with the LLMTR key or with a request reaching LLMTR, LLMTR support can help.

Which errors are worth retrying?

429 provider_rate_limited and 502 provider_upstream_error can be retried after a wait. 403 errors and other 4xx responses do not change on retry.

Related posts

• Building a team application without sharing the EVREN key
• The difference between an EVREN request record and a prompt record

• EVREN guide
• Model catalog