Bring your own key
BYOK routes IDPForge's model calls through your own LLM provider account, so provider billing goes to you and IDPForge charges only its platform fee.
What BYOK changes
By default IDPForge runs model calls on its own provider accounts and bills you in credits for them. With bring your own key (BYOK) you add your own provider keys, and IDPForge routes inference through your account instead: the provider's token bill goes to you, and IDPForge charges only its platform fee. The flat platform charge and any non-LLM processing still apply.
BYOK in Settings → Integrations. Provider pools group your keys; pipelines route through a provider's default pool automatically.
Providers, pools, and keys
BYOK is organised in three layers.
- Provider — OpenAI, Anthropic, and the other LLM providers IDPForge supports.
- Pool — a named group of keys for one provider, sharing a region and a monthly cap. Each provider has a default pool that pipelines use unless one is pinned. A pool load-balances across its keys — for example round-robin — and can carry a monthly spend cap.
- Key — a single provider credential in a pool, with an alias and a status.
A pool shows what it is doing at a glance: how many keys it holds, its region, its cap, when a key was last rotated, and how many pipelines route through it.
Per-call billing
BYOK applies per model call, not per job. A job can touch more than one provider; each call to a provider you have configured uses your key and carries no LLM surcharge, while a call to a provider you have not configured falls back to IDPForge-managed inference and is charged in credits. A fully BYOK pipeline shows no LLM surcharge at all.
Fail-closed safety
If a pipeline is configured to use your key for a provider but no usable key is available when a job starts — every key disabled, or the credential cannot be resolved — the job fails rather than quietly running on IDPForge-managed inference. Failing closed means you are never billed in credits for spend you configured BYOK to self-fund.
Routing controls
- Org routing lock — force every pipeline through IDPForge-managed inference, ignoring any per-pipeline BYOK overrides. Per-pipeline pinning is blocked while the lock is on.
- Per-pipeline pool pin — pin a specific pool for a pipeline, usually to isolate rate limits, rather than using the provider default.
How keys are stored
Provider keys are held in an encrypted secret store; the application database keeps only metadata and a reference, never the secret itself. Keys are partitioned by environment, so your sandbox and production credentials are stored separately.
To add a key, see Add your own LLM key.