Home/Providers/Fallback Policies ENУКРРУС API Reference (ReDoc) ↗

Fallback Policies

What a provider does with a regional language nobody configured — and why none of them are strict.

A provider's fallback_policy decides one thing: what to answer for a regional language with no explicit row. It never affects base languages, and it never overrides a row that exists.

It is reported on the provider: GET /v1/providers/{code} returns it in fallback_policy, so a caller can tell in advance how an unconfigured pair will be answered.

The three policies

base_language

Send the base language's code. pt-BR → pt, de-CH → de, ar-EG → ar.

{ "language": "pt-BR", "code": "pt", "match": "base_language", "via_language": "pt" }

You lose the regional distinction, but you get a code the provider certainly understands. This is what every provider currently uses.

passthrough

Send the canonical code unchanged. pt-BR stays pt-BR.

{ "language": "pt-BR", "code": "pt-BR", "match": "passthrough" }

For engines whose accepted set is not a standard: a customer-trained model knows exactly the tags it was trained on, and truncating to a base tag is a worse guess than not truncating.

strict

Answer supported: false, code: null. Do not guess.

{ "language": "pt-BR", "code": null, "supported": false, "match": null }

For APIs that reject unknown tags with a 4xx, once it is known which pairs actually work. A wrong guess there costs a failed job; failing early is cheaper.

Why no provider is currently strict

Some vendors — DeepL, Azure, Amazon among them — really do return 400 for a tag they do not recognise, and their notes field says so. They are still on base_language, deliberately.

base_language truncation is right far more often than it is wrong: an unmapped pt-BR reaches such an API as pt, which is a tag they all accept. Only a minority of regional languages have an explicit row for any given provider, so switching one to strict would turn every remaining pair — including the many that work today — into supported: false at once.

The rule

strict is a per-provider opt-in, turned on after that provider's genuinely unsupported pairs have been recorded explicitly — not before. Marking a pair unsupported is a statement of fact; marking a whole provider strict is a statement about everything nobody has checked.

The provider notes field carries the shortlist of candidates, so a caller can see which providers are strict-shaped even while they answer permissively.

What this means for a caller

If a pair matters to you, read match:

  • exact — configured deliberately for this pair.
  • base_language / passthrough — derived by the policy. Correct and usable, but nobody has verified this exact pair against that API.

A pair that is known not to work answers supported: false with code: null, whatever the policy is. That is a recorded fact about the pair, not a fallback — do not attempt the request.

A refusal recorded against a base language covers its regional variants too. A provider that does not translate German cannot translate de-AT, so both answer supported: false, and via_language names the language the refusal was recorded against. The policy never runs for those pairs: it decides what to do when nothing is known, and here something is.

Next