Skip to main content
Relay uses two distinct credential types.

​
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 keys with an expiry for trials and separate keys for each production environment.

​
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. After you save a provider credential, Relay does not display the secret again. Enter a replacement when you need to rotate it. 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.

Set limits

Apply project and key-level spend and rate controls.

Build a routing policy

Choose from callable, routable candidates and set a fallback.