> ## Documentation Index
> Fetch the complete documentation index at: https://oximy.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Keys, providers, and models
> Manage Relay authentication, bring your own provider credentials, and understand model availability.
Relay uses two distinct credential types.
| Credential | Purpose | Presented to |
| ------------------- | -------------------------------------------------------------- | --------------------------------------------- |
| Relay key | Authenticates an application and identifies its project policy | Relay gateway, route endpoint, or OTEL ingest |
| Provider credential | Allows Relay to execute a request against a model provider | Stored and used by Relay for that project |
## Relay keys
Relay keys are project-scoped and begin with `ox_`. The full value appears only when the key is created; later views show a prefix.
A key can have:
* a name
* a requests-per-minute limit
* a monthly budget
* an expiry time
* project-setting overrides
* key-group membership where policy requires it
Disable or revoke keys that should no longer authorize requests. Prefer short-lived keys for trials and environment-specific durable keys for production workloads.
## Provider credentials
Provider credentials are bring-your-own-key connections. Add them under **Relay → Providers**, then verify each connection with a real provider check.
Relay records whether a provider connection is verified, failed, or unchecked, plus the latest verification time and error. Secret material is accepted during upsert but is not returned by the control plane.
An optional API base URL supports provider-compatible endpoints that require a non-default base.
Rotating a provider credential can affect every Relay key in the project that routes to that provider. Verify the replacement before removing the old execution path.
## Model catalog
The catalog describes provider, model family, modalities, reasoning and tool-call support, limits, price data, and release metadata. Two availability flags matter:
* **Callable**: the project has the provider access needed for Relay to execute the model.
* **Routable**: the routing engine can include the model in an automatic or custom-router candidate set.
A model can be callable but not routable. In that case, request it directly if supported, but do not add it to an automatic candidate set.
Apply project and key-level spend and rate controls.
Choose from callable, routable candidates and set a fallback.