> ## Documentation Index
> Fetch the complete documentation index at: https://dev-docs.altrum.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Provider credentials

> Store your organization's own model provider credentials in Altrum, or let callers send their own.

Altrum calls model providers with your organization's own accounts. You pay your providers as you do today. Altrum stores the credentials so your applications never need them: an application holds only an Altrum virtual key.

## Supported providers

| Provider | What you store |
| - | - |
| OpenAI | An API key |
| Anthropic | An API key |
| Google Gemini | An API key |
| Google Vertex AI | Your project, your region and a service account key |
| Bedrock | Your region, and either an API key or an access key with its secret (and a session token, only for temporary access). Optionally, the inference profiles your model names map to |
| Azure | Your endpoint and the deployments your model names map to, and either an API key or the client id, client secret and tenant id of an app registration |

## Add a credential

Owners and admins open **AI Gateway**, then **Provider credentials**, and choose **Add credential**. Name it, choose the provider and fill in what that provider needs. Under **Models**, list the models it may serve, or leave it empty for every model. The list shows each credential as **In use**, **Off**, or **Needs attention** with the provider's reason when the provider refused it.

| Field | Limit |
| - | - |
| Name | 1 to 100 characters |
| Secret | Up to 20,000 characters |
| Models | Up to 200, each up to 200 characters; `*` is every model |
| Model names mapped to deployments or inference profiles (Azure, Bedrock) | Up to 100 |
| Endpoint (Azure) | An https address, up to 2048 characters |
| Region (Vertex, Bedrock) | The region name exactly as the provider shows it, up to 40 characters |

* A credential is encrypted when it is stored, and never shown again. The list shows only its last characters.
* Altrum never writes a credential into a log.
* To replace a credential, store the new one and remove the old one. Removing asks you to confirm: requests stop using it straight away, and keys that reach that provider only through it fail until you add another.
* A stored credential can be renamed, switched off and limited to some models, but its secret cannot be edited.
* You can store several credentials for one provider, for example for different accounts or regions. Requests to that provider use all of them.
* The models a credential lists are the models anyone in your organization can reach through it. Each key can narrow them further. See [Models and routing](/ai-gateway/models-and-routing).

## What Altrum refuses to store

Altrum calls a provider from the Altrum network, so it refuses a credential that would reach anything else:

* An address that is not public: an Azure endpoint must be an https address that anyone on the internet could reach. An address inside a private network, or one that points back at Altrum, is refused.
* A reference to somewhere else instead of the value itself, such as the name of an environment variable.
* A credential that relies on the machine Altrum runs on to sign in. A Bedrock credential needs its own API key or access key, a Vertex credential its own service account key, and an Azure credential its own API key or app registration. Altrum never signs in as itself on your behalf.
* For Vertex, anything other than a service account key.

Each refusal names the field, as the AI Gateway calls it, and what to send instead. For example:

```
vertex_key_config.auth_credentials must be a service account key (type service_account)
```

## Callers' own credentials

Some teams want an application to send its own provider credential with each request. This is off by default. An owner or admin can switch on **Callers may send their own provider key** under **AI Gateway**, **Settings**, **Access**.

The request sends the header `x-alt-direct-key: true`, its provider credential in `Authorization: Bearer`, `x-api-key` or `x-goog-api-key`, and its Altrum virtual key in `x-alt-vk`. A request that sends its own credential must also carry an Altrum virtual key, so Altrum knows which organization it belongs to, and is refused if the organization has not switched this on:

| Status | Message |
| - | - |
| 401 | `a direct provider key must be sent with a virtual key in x-alt-vk, so Altrum knows which organization it is for.` |
| 403 | `direct provider keys are not enabled for this organization. An owner can turn them on in the AI Gateway settings.` |

A credential sent this way is used for that request only, never stored and never logged. Guardrails, rate limits and logging still apply. Its cost is counted against budgets, but your provider bills the caller's account.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.