LLM gateway admin API¶

The LLM gateway is a centralized service that manages access to LLMs from external providers. It offers several key benefits:

• Policy enforcement and granular access of approved LLMs.
• Standardized interactions with multiple LLM providers.
• Security, monitoring, and cost controls across all LLM usage.
• Dynamic model selection for agents, providing access to LLMs in the gateway catalog to support task optimization.

The following endpoints let an organization administrator scope the LLM gateway functionality to their own organization:

• Default credential rule overrides: Sets which credential the gateway uses by default when routing requests to a given provider or model, for each user in the organization.
• Custom LLM catalog entries: Configures self-registered LLMs (for example, a model your organization has direct provider access to) so they appear in your tenant's LLM catalog alongside the DataRobot-managed models.
• Permission rules: Specifies user, group, and organization-level access for a given LLM, LLM family, or provider. "Family" in this API is a synonym for "Publisher" as seen in the UI.

Authentication and access¶

All endpoints on this page require the same Bearer token authentication as the rest of the DataRobot public API (an API key or OAuth token for a DataRobot user):

Authorization: Bearer YOUR_API_TOKEN

The authenticated user must also hold the organization administrator role in their tenant, and must not belong to a trial organization—these endpoints return 403 Forbidden for trial users regardless of role.

There is no request parameter for selecting a tenant or organization. Every operation reads and writes only the caller's own tenant, derived from their authentication. You cannot view or modify another tenant's credential rules or catalog entries through this API.

Base path¶

All paths below are relative to the following base path:

/api/v2/genai/llmgw/admin

Access policy for new entries¶

A catalog entry you create becomes visible in GET /catalog/ and usable in chat completions as soon as it is created, with no separate activation or registration step. Visibility and usability follow the same access policy as every other LLM—evaluation checks for a rule at the LLM level first, then the publisher level, then the provider level—and uses the first level that has one configured. In practice, a new entry automatically inherits whatever provider- or publisher-level policy your organization already has (for example, a "Default allow" on Bedrock), with no extra step required. If your organization has no policy at all for the entry's provider or publisher, and the entry is not a preview LLM, it starts out denied by default until you configure access. This is the same default-deny behavior applied to a new DataRobot-managed LLM.

Permission rules¶

Use the permission rule endpoints to configure provider-, publisher-, or LLM-level policy directly in the gateway for controlling access on a user, group, or organizational level. Rules can be set at any of the three levels; a level with no direct rule of its own falls back to the next level up, as described in Access policy for new entries.

Get the permission tree¶

GET /permissions/

Returns every provider your organization can configure permissions for (see Provider values) together with their LLM families. Not paginated—the number of providers and families is small and fixed.

Response—200 OK:

{
  "providers": [
    {
      "name": "Amazon Bedrock",
      "slug": "bedrock",
      "permissions": {
        "orgAllow": true,
        "overrides": {
          "users": [
            {
              "id": "65f1a2b3c4d5e6f7a8b9c0d1",
              "name": "Ada Lovelace",
              "username": "ada@example.com",
              "allow": false
            }
          ],
          "groups": []
        }
      },
      "families": [
        {
          "name": "Anthropic",
          "slug": "bedrock__anthropic",
          "permissions": null,
          "modifiedAt": null,
          "modifiedBy": null
        }
      ],
      "modifiedAt": "2026-08-01T12:00:00Z",
      "modifiedBy": {
        "id": "65f1a2b3c4d5e6f7a8b9c0d1",
        "name": "Ada Lovelace",
        "username": "ada@example.com"
      }
    }
  ]
}

Provider object

Family object (nested under families)

List LLMs with permissions¶

GET /permissions/llms/

Query parameters

If both provider and family are given, family must belong to provider.

Response—200 OK, a paginated object in the same shape as Custom LLM catalog entries:

{
  "totalCount": 1,
  "count": 1,
  "next": null,
  "previous": null,
  "data": [
    {
      "model": "bedrock/anthropic.claude-sonnet-4-5-20250929-v1:0",
      "name": "Claude Sonnet 4.5",
      "permissions": null,
      "creator": "Anthropic",
      "retirementDate": null,
      "isDeprecated": false,
      "isActive": true,
      "modifiedAt": null,
      "modifiedBy": null
    }
  ]
}

Errors

Update permission rules¶

POST /permissions/

Sets the allow/deny/remove state of one or more (resource, subject) rules in a single request.

Request body

Each item in data:

Response—204 No Content.

Errors

Delete permission rules¶

DELETE /permissions/

Deletes every rule on one resource—both the allow-rule and the deny-rule, for every subject—resetting it to have no direct rule at all. Rules inherited from the resource's parents will then govern the resource, if any exist.

Request body

Response—204 No Content. Deleting a resource with no existing rules is a no-op, not an error.

Errors

Permission object¶

The permissions field on a provider, family, or LLM entry is null when no rule is configured directly on that resource. Otherwise:

{
  "orgAllow": true,
  "overrides": {
    "users": [
      {
        "id": "65f1a2b3c4d5e6f7a8b9c0d1",
        "name": "Ada Lovelace",
        "username": "ada@example.com",
        "allow": false
      }
    ],
    "groups": [
      { "id": "65f1a2b3c4d5e6f7a8b9c0d4", "name": "Engineering", "membersCount": 12, "allow": true }
    ]
  }
}

If the gateway can no longer resolve a user or group (for example, it was removed, or it belongs to a different tenant), it still appears in overrides, with name (and username, for users) returned as null.

Resource types¶

datarobot and mock cannot be used as a provider resource—self-hosted models are not access-controlled through this API, and mock is a test-only provider that skips access evaluation entirely.

Permission states¶

Subject types¶

Credential rule overrides¶

A credential rule tells the gateway which stored credential to use, by default, for requests to a given LLM provider (optionally narrowed to one model) from anyone in your tenant. Use this to point the gateway at your organization's own provider credentials instead of DataRobot's shared default pool.

List credential rule overrides¶

GET /credentials/

Returns every default credential rule configured for the tenant.

Query parameters

Passing both llmProvider and model returns 400 Bad Request.

Response—200 OK, a JSON array of credential rule objects.

Create a credential rule override¶

POST /credentials/

Creates a default credential rule for the tenant. You cannot set the scope explicitly—a rule created here always applies to your own tenant.

Request body

Response—201 Created, a credential rule object.

Errors

Delete a credential rule override¶

DELETE /credentials/{credential_id}/

Deletes one credential rule belonging to the tenant.

Path parameters

Response—204 No Content.

Errors

Credential rule object¶

{
  "id": "65f1a2b3c4d5e6f7a8b9c0d1",
  "scope": {
    "scope": "tenant",
    "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
  },
  "credential": {
    "source": "dr_secure_config",
    "id": "65f1a2b3c4d5e6f7a8b9c0d2"
  },
  "llmProvider": "bedrock",
  "model": null
}

Credential reference object¶

Provider values¶

Valid provider values are: azure, bedrock, vertex_ai, anthropic, cohere, openai, togetherai, cerebras, groq, alibaba, and other.

The special value other circumvents the logic normally used to build a model string for each provider. When using other in a credential rule, the credential JSON must have the following shape, including the field api_base to provide the base URL that should receive requests.:

{
    "endpoints": [
        {
            "region": "global",
            "api_base": "<your-base-url>",
            "api_key": "<your-api-key>",
        }
     ]
}

Custom LLM catalog entries¶

A catalog entry describes one LLM to make available to your organization; it uses the same shape as DataRobot's own globally available LLMs. Entries you create here are scoped to your tenant only, and never affect or become visible to other organizations.

List catalog entries¶

GET /llms/

Query parameters

Response—200 OK, a paginated object:

{
  "totalCount": 1,
  "count": 1,
  "next": null,
  "previous": null,
  "data": [ /* array of catalog entry objects, see below */ ]
}

Create a catalog entry¶

POST /llms/

Request body

Response—201 Created, a catalog entry object.

Errors

Get a catalog entry¶

GET /llms/{entry_id}/

Response—200 OK, a catalog entry object.

Errors—404 Not Found if the entry does not exist or belongs to another tenant or to the global catalog.

Update a catalog entry¶

PATCH /llms/{entry_id}/

Partial update: send only the fields you want to change, in a plain JSON object (either camelCase or snake_case field names, not a mix of both spellings of the same field in one request).

Request body—any subset of the mutable fields. All other fields listed under Create a catalog entry except provider, creator, and model are mutable; provider, creator, model, llmId, customModelDeploymentId and the identity fields below are immutable—delete and recreate the entry to change any of those.

Response—200 OK, the updated catalog entry object.

Errors

Delete a catalog entry¶

DELETE /llms/{entry_id}/

Response—204 No Content.

Errors—404 Not Found if no such entry exists in your tenant.

Catalog entry object¶

{
  "id": "65f1a2b3c4d5e6f7a8b9c0d3",
  "scope": { "scope": "tenant", "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6" },
  "provider": "bedrock",
  "creator": "Anthropic",
  "model": "bedrock/anthropic.claude-sonnet-4-5-20250929-v1:0",
  "llmId": "my-tenant-claude-sonnet",
  "name": "Claude Sonnet 4.5 (tenant BYO)",
  "version": "2025-09-29",
  "description": "Tenant-registered Claude Sonnet 4.5 via our own Bedrock account.",
  "license": "See provider terms",
  "supportedLanguages": ["Multilingual"],
  "contextSize": 200000,
  "maxCompletionTokens": 64000,
  "inputTypes": ["text", "image"],
  "outputTypes": ["text"],
  "capabilities": ["tool_calling", "reasoning"],
  "documentationLink": "https://...",
  "referenceLinks": [],
  "dateAdded": "2026-09-09",
  "retirementDate": null,
  "isPreview": false,
  "isMetered": false,
  "availableForTrial": false,
  "isDeprecated": false,
  "isActive": true,
  "crossRegionInferenceMap": {},
  "availableRegions": [],
  "availableLitellmEndpoints": { "supportsChatCompletions": true, "supportsResponses": false },
  "unsupportedParams": [],
  "resourceCodes": [],
  "permissionId": "65f1a2b3c4d5e6f7a8b9c0d3"
}

Fields not covered in Create a catalog entry:

isMetered and resourceCodes are yours to set—see Create a catalog entry. Unlike DataRobot-billed catalog entries, your own provider usage is unmetered by default; opting in only gets you usage stats against resource codes you define, not DataRobot billing.

Server-assigned fields¶

The following fields are assigned by the server: id, permissionId, dateAdded, availableForTrial, isDeprecated, isActive, unsupportedParams. Sending any of these in a POST request body is rejected with 422.

Mutable fields¶

Every field on the entry except id, scope, permissionId, provider, creator, model, llmId, and customModelDeploymentId can be changed with PATCH. The excluded fields define what the entry is or routes to. To change them, delete and recreate the entity.

Valid provider/creator pairings¶

A provider/creator combination not listed in this table is rejected with 422 Unprocessable Entity. cerebras and groq currently have no valid tenant-entry pairing.

Common error responses¶