Roadie is BYOK (bring your own key): you add your own OpenAI and Anthropic API keys, and the gateway calls the providers on your behalf using them. You keep your provider billing relationship; Roadie never resells provider tokens at MVP. Two providers are supported today — OpenAI and Anthropic — through the unified chat and embeddings schema, plus OpenAI image generation and editing (see Images below).

​
Adding a credential

In the dashboard, add a provider credential to a project. You can scope it to a single environment or to all environments in the project (a project-wide credential with no environment_id). On save, Roadie makes a live validation call to the provider and records the result — an invalid key is rejected up front and never quietly stored as usable.

​
How a credential is protected

A provider secret is treated as unrecoverable key material the moment it arrives:
  • It is envelope-encrypted before it touches the database — a per-secret data key (AES-256-GCM) encrypts the bytes, and that data key travels wrapped by the master key (local master key in dev, AWS KMS in production).
  • The ciphertext is bound to org:project:credential as additional authenticated data, so a row copied under another id or tenant fails to decrypt — a leaked database row is useless on its own.
  • Only a display fingerprint (the last 4 characters) is kept in the clear.
  • The plaintext is never re-readable through the API after creation. You can validate, rotate, or delete a credential, but you cannot read it back.
The gateway is the only component that decrypts a provider secret, in memory, at request time, for the single provider call. Under production KMS only the gateway’s role can call Decrypt at all.

​
How a credential is selected

When a request resolves to a provider (say openai), the gateway picks that environment’s credential for that provider from the config snapshot. If no credential exists for the resolved provider, a direct provider/model request fails before any provider work with invalid_request_error / provider_credential_missing. An alias target may pin a specific credentialId if you maintain more than one key per provider; otherwise the environment’s default for that provider is used. An alias target with no usable credential is simply skipped, so the alias still routes as long as one eligible target remains.

​
Images use your OpenAI key

Image generation and editing run on OpenAI’s gpt-image-1 through the same OpenAI credential — there is no separate image key to add. Requests go through the OpenAI-compatible image endpoints (POST /openai/v1/images/generations and /openai/v1/images/edits); there is no native /v1/images surface. Image requests flow through the same routing, fallback, metering, and privacy machinery as chat and embeddings. One privacy detail is specific to images: the image bytes are never written to your request logs. Only the prompt text, an [omitted:image] marker, and generation metadata are captured — see Privacy modes.

​
Rotation

Rotating a credential is add-validate-delete:
  1. Add the new provider key (validated live on save).
  2. Confirm traffic succeeds.
  3. Delete the old one.
Because the gateway reads credentials from the config snapshot, updates propagate on the config-dirty push (and, at worst, within the snapshot TTL). See the BYOK rotation guide for a zero-downtime walkthrough.

​
Secrets never leak downstream

Provider keys never appear in responses, request logs, usage records, or error messages — every credential DTO carries only the masked fingerprint, and the platform logger additionally redacts secret-shaped strings everywhere. If a provider returns an error, the gateway maps it to a provider_error with a safe message — never the provider’s raw body.

​
Supported providers

OpenAI and Anthropic are supported today. More providers, and a platform-managed-keys option, are on the roadmap.