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).

  1. 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.

  2. Restrict providers

    In the Restrictions step, you narrow down the providers:

    SettingEffect
    Data residencyAllows 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 exposureExcludes providers that are subject to the CLOUD Act.
    Only §203-covered providersAllows only providers with an agreement under § 203 StGB.
    ProvidersAllows 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.

  3. Check the selection with the key

    GET /v1/models lists 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.

    Shell
    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.
JSON
{
  "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.