Skip to main content

Provider keys and custom deployments

Organizations can bring their own inference credentials into Devs.ai so models run on your provider contracts instead of debiting your platform balance. There are two related capabilities:

  • Provider Keys — Store organization API keys for supported native providers (such as OpenAI and Anthropic).
  • Custom deployments — Register OpenAI-compatible hosts (Azure AI Foundry, vLLM, Ollama, custom URLs, and similar) and expose one or more model names from each endpoint.

Both are optional and not enabled by default. Contact your Devs.ai representative to request access for your organization.

📝 Note: Provider Keys and Custom deployments are independent. You can use custom deployments for self-hosted models without adding native provider keys, and you can add provider keys without registering custom endpoints.

Who can manage these settings​

  • Provider Keys and Custom deployments appear under Organization when the corresponding capability is enabled for your org.
  • You need organization settings read permission to view configuration and write permission to add, update, or remove keys and deployments.
  • End users do not manage keys; they simply see eligible models in pickers when admins have made them available.

Provider Keys​

What provider keys do​

When your organization stores a provider key, inference for that provider’s models can use your API key instead of the platform key. Successful runs on your key are billed as bring your own key (BYOK)—$0 platform debit for that usage—while token counts are still recorded for analytics.

If no org key exists for a provider, the product falls back to platform keys and normal platform billing for that provider’s models.

Adding and managing keys​

  1. Open Organization → Provider Keys.
  2. For each supported provider, add an API key using the password-style field (the full key is never shown again after save).
  3. Replace or delete a key from the same page. Deleting a key returns that provider to platform-key inference.

Keys are stored encrypted. List views show only a masked prefix (for example, sk-...****).

What users see​

Provider key configuration does not change the model picker by itself. Models still follow Organization model settings. When your key is active, eligible requests against that provider use your credentials and BYOK billing.

If a provider key is invalid or exhausted, users may see a generic error asking them to contact an administrator. Admins should verify the key in the provider’s console and billing status.

Custom deployments​

What custom deployments do​

Custom deployments let you register endpoints you operate that speak an OpenAI-compatible HTTP API. For each endpoint you add one or more external model IDs with display names that appear in the catalog. Inference runs against your host using your credentials; usage is treated as BYOK ($0 platform debit on the platform ledger).

Examples include:

  • Azure AI Foundry (OpenAI-compatible route)
  • vLLM or Ollama on an internal URL
  • Other gateways that expose /v1/chat/completions or the OpenAI Responses API

Registering a deployment​

  1. Open Organization → Custom deployments.
  2. Start the wizard and choose an OpenAI-compatible endpoint type.
  3. Pick a preset (for example Azure AI Foundry or custom URL) or enter connection details: base URL, API key, and optional advanced headers.
  1. Choose the upstream API style where applicable:
    • Chat completions — standard /v1/chat/completions hosts (default for many self-hosted stacks)
    • Responses — hosts that implement the OpenAI Responses API (common for Foundry-style routes)
  2. Add models: for each row, set the model ID your host expects and a display name members will see in pickers.
  3. Save the deployment.

You can register multiple models per endpoint (for example several deployments behind one vLLM URL).

Making custom models available to users​

After models are registered, open Organization model settings and include them in your allowlist (when restriction is on) and per-surface availability. Until then, custom models may not appear in chat, App Builder, agents, or routines.

Managing and removing deployments​

From Custom deployments you can edit endpoint credentials, add or remove models, and delete deployments you no longer need. Disabling the custom deployments capability for your org hides the admin UI but does not delete stored configuration; re-enabling restores access.

Deleting an endpoint that still has models may be blocked until you remove dependent models first.

Billing and analytics​

ModePlatform balanceProvider billing
Platform key (default)Normal usage debitN/A
Org provider key (BYOK)$0 debit for that invocationYou pay the provider directly
Custom deployment (BYOK)$0 debit for that invocationYou pay for your host / cloud

Usage and analytics still record token counts and model names so you can monitor adoption. Displayed costs for BYOK runs reflect zero platform charge.

Security and limitations​

  • API keys and endpoint secrets are never returned in full from the API after they are saved.
  • Custom deployment base URLs are validated in production to reduce unsafe internal routing.
  • Provider Keys currently cover OpenAI and Anthropic native overlays. Other native providers may still use platform keys only.
  • Custom deployments focus on OpenAI-compatible hosts; native Azure OpenAI catalog routes and other platform-managed deployments are separate from this wizard.
  • Bedrock, Vertex, and additional native BYOK surfaces may roll out under the same capability over time—follow in-product labels for what your org can configure today.
⌘J