Develop / Guides
Restrict models & providers
How to define which models and providers an API key may reach, and how classifying your organisation under professional secrecy (§ 203 StGB) narrows the selection.
A new API key may call every model of your organisation. You set restrictions per key. They take effect immediately and apply to all endpoints, including your own providers (BYOK).
-
Select models
Admins of your organisation create keys under Models → API keys with New key. The Models step offers two options:
- All models (default): new models of the organisation are included automatically.
- Selected models only: the key stays limited to the selection.
For existing keys, you change the selection through Details & edit.
Result: the key reaches the selected models.
-
Restrict providers
In the Restrictions step, you narrow down the providers:
Setting Effect Data residency Allows providers with the selected location. “EU” also includes providers with a location in an EU member state. Without a selection, every location is allowed. Only providers without CLOUD Act exposure Excludes providers that are subject to the CLOUD Act. Only §203-covered providers Allows only providers with an agreement under § 203 StGB. Providers Allows the selected providers. Without a selection, all are allowed. If more than one allowed provider offers a model, the gateway takes your own providers (BYOK) first, otherwise the cheapest managed provider. If you select a single provider, the key is bound to it. Providers & routing explains the order.
Result: under Matches, the portal shows how many providers and models the key still reaches.
-
Check the selection with the key
GET /v1/modelslists the models that the calling key reaches. Restrictions of the key and of the organisation are already applied.Result: the list contains the allowed models and no others.
curl https://api.noirdoc.de/v1/models \ -H "Authorization: Bearer $NOIRDOC_API_KEY" \ | jq -r '.data[].id'
Rejected requests
If a key requests a model outside its restrictions, the gateway answers with 403. The request reaches no provider.
model_not_allowed_for_key: the model is not in the key’s model selection.provider_not_allowed_for_key: no provider of the model meets the key’s restrictions.
{
"error": {
"type": "permission_error",
"code": "model_not_allowed_for_key",
"message": "Model 'qwen3.8-27b' is not permitted …",
"param": null
}
}Professionals bound by secrecy (§ 203 StGB)
Whether your organisation counts as bound by professional secrecy is set by the answer to the question on § 203 German Criminal Code (StGB) during setup on Getting started (or in your organisation settings). Under Models → Shield, the portal shows this as the §203 client badge. The classification applies in addition to the key’s restrictions:
- Models offered only by managed providers without an agreement under § 203 StGB are missing from
GET /v1/models. - Requests to models that have only such providers end with 403
provider_not_allowed_for_tenant. - The mode does not filter your own providers (BYOK).
The Only §203-covered providers setting on the key, by contrast, also filters your own providers. Professional secrecy describes what the mode checks technically.
Errors
| Status | Code | Meaning |
|---|---|---|
| 403 | model_not_allowed_for_key | The model is not one of this key's allowed models. |
| 403 | provider_not_allowed_for_tenant | The organisation counts as bound by professional secrecy (§ 203 StGB); this excludes every provider that offers this model. |
| 403 | provider_not_allowed_for_key | The key's restrictions (providers, data residency, CLOUD Act, § 203) exclude every provider of this model. |
| 403 | starter_model_not_allowed | The organisation is still using only its starter credit, and the model or its managed provider is not included in starter credit. |
| 404 | model_not_available | The model ID is not available to the organisation. |