AI steps in a logic block call a provider — Anthropic, OpenAI, Gemini, or any OpenAI-compatible API. Provider configuration resolves bottom-up through three tiers, so the platform sets defaults, the org decides which providers are allowed, and each workspace supplies its own keys.
The three tiers
- Org catalog — the set of providers that exist for this org (name/protocol/default model), curated by the org admin from a platform-seeded starting set. No keys.
- Org allowlist — an enable/disable gate per provider, set by the org admin. A tenant can only *save a key* for an allowlisted provider — the gate is enforced at save time, not on every call, so a provider removed from the allowlist later doesn't break a workspace that already has a key saved for it.
- Workspace (tenant) — the actual API key and default model, stored as a settings record.
A workspace provider record
Each provider is a settings record with group = aiprovider. Tenants save these through your app's settings UI using the standard settings entity endpoints — the active flag enables/disables a provider without deleting its key.
{
"group": "aiprovider",
"name": "openai",
"active": true,
"value": {
"api_key": "sk-...",
"default_model": "gpt-4o-mini",
"protocol": "openai"
}
} The value shape is the same for every provider:
- `api_key` (required) — the provider key.
- `default_model` — used when a step omits
model. - `protocol` (required) — the wire adapter:
openai,anthropic, orgemini. - `base_url` — an OpenAI-compatible endpoint override (Grok, DeepSeek, Mistral, …).
OpenAI-compatible providers need no code
To add Grok, DeepSeek, or any OpenAI-compatible API, write a record with protocol: "openai" and the provider's base_url. A genuinely new wire protocol is the only thing that needs platform work.
How a call resolves
Keys stay server-side
Provider keys live in workspace settings and are used only by the runtime. They are never returned in an API response.