Connect a provider credential
Add an upstream provider and publish its models to the catalog.
A credential holds the upstream API key AOCore uses to reach a model provider. Adding one can populate the model catalog automatically, so this is usually the fastest way to make a new provider’s models available.
Steps
1. Open /credentials.
2. Click Add Credential.
3. Enter the key first. Typing an API key auto-selects the provider from its
prefix (sk-ant- → Anthropic, gsk_ → Groq, sk-or- → OpenRouter, pplx- →
Perplexity, and so on), which then fills the API base and any required auth
header. Override the provider manually if the guess is wrong.
| Field | Notes |
|---|---|
| Name | How the credential is referenced. |
| API Key | Stored encrypted; redacted on every read. |
| Provider | Usually auto-selected from the key prefix. |
| API Base | Endpoint host. Auto-filled from the provider preset. |
| API Key Header | For endpoints expecting the key in a custom header rather than Authorization. |
4. Save. If the credential declares an endpoint, AOCore queries that
endpoint’s /v1/models and registers every model it finds, bound to this
credential. A single credential add commonly turns an empty catalog into a
populated one.
5. Confirm at /models.
Provider-specific notes
AWS Bedrock uses SigV4, not a bearer token. Selecting Bedrock switches the
form to Access Key ID / Secret / Region / optional Session Token. Bedrock exposes
no /v1/models, so its models are added manually.
Azure AI Foundry is per-resource: replace the YOUR-RESOURCE placeholder in
the API base with your resource name. Not environment-provisionable — add it
manually.
Custom header auth. Some gateways (including a downstream AOCore fronted by
AOEdge) expect the key in X-API-Key and reject Authorization outright. Set
API Key Header to X-API-Key; the key is then sent in that header and
Authorization is omitted rather than sent alongside.
Provisioning from the environment (development only)
If the gateway’s own environment already holds provider keys, /credentials
offers Quick add from environment: pick a detected provider and the
credential is created server-side. The key is read from the gateway’s
environment and never reaches the browser.
This is disabled outside development, by design — production credentials come from the secret store.
Secrets handling
- Keys are encrypted at rest.
- Every string inside
credential_infois redacted on read — not just the key field. An administrator listing credentials sees***REDACTED***, never material. - Consequently there is no “show key” affordance. To rotate, replace the credential.
Verifying a credential works
Send a request through /playground against a model bound to the credential. A
misconfigured credential surfaces as an upstream error with the provider’s own
status passed through — a 401 means the key is wrong, a 404 naming the model
means the model id is wrong for that provider, and a 429 carries the
provider’s Retry-After. Those upstream statuses reach you rather than being
flattened into a generic gateway error, which is what makes this diagnosable.