Connect your tools

Create an API key in your console, then choose the client you use. Keep keys private and use a different key for each device.

API reference

Import the OpenAPI 3.1 document into your API client to explore requests, response fields and errors for text generation, models, key status, usage, wallet balance, media jobs and management operations.

Download the OpenAPI document (JSON)

The document contains no credentials. Add your key locally as a bearer token; never include it in a shared collection or URL. Its default server is the production API—change the server explicitly when testing another environment. Signing up, payments and invoices are managed in the console.

# Public schema; no API key required:
GET https://api.deepxroute.com/v1/openapi.json

# For API requests, send one authentication header:
Authorization: Bearer <your DeepXRoute API key>
# Alternative: x-api-key: <your DeepXRoute API key>

Each text-generation POST is a new request. Disable automatic SDK retries: a timeout can leave credit held while usage is checked. For media, save the submission UUID and reuse it with the same content after an uncertain response. Check the job before starting another generation. A successful key check does not activate provisional pricing or add wallet credit.

Claude Code

Set these environment variables in your local tool configuration. Use your Deep X Route key as the authentication token.

ANTHROPIC_BASE_URL=https://api.deepxroute.com
ANTHROPIC_AUTH_TOKEN=<your Deep X Route API key>
ANTHROPIC_MODEL=dxr-coder-pro
ANTHROPIC_DEFAULT_SONNET_MODEL=dxr-coder-pro
ANTHROPIC_DEFAULT_OPUS_MODEL=dxr-coder-pro
ANTHROPIC_DEFAULT_HAIKU_MODEL=dxr-coder-fast

Remove a conflicting ANTHROPIC_API_KEY override from that configuration. Restart Claude Code after updating the environment.

Codex

Set DEEPXROUTE_API_KEY securely in your environment, then add this provider to your Codex configuration. Back up existing settings before editing them.

model = "dxr-coder-pro"
model_provider = "deepxroute"

[model_providers.deepxroute]
name = "Deep X Route"
base_url = "https://api.deepxroute.com/v1"
env_key = "DEEPXROUTE_API_KEY"
wire_api = "responses"

Compatible SDKs

Use https://api.deepxroute.com/v1 as your base URL and your Deep X Route key for bearer authentication. Choose an available model from the console’s price list.

Text, streaming and client-executed function calls are supported. Image and video generation use the separate media endpoints below. Audio, image inputs to chat, background responses and server-hosted tools are not supported.

Find a model and its API example

Search the model catalog by name or API ID, filter by output type, then open a model to copy a cURL, JavaScript or Python example. Model links can be bookmarked and shared; they contain no API keys. Prices and limits come from the current platform configuration.

GET https://api.deepxroute.com/v1/models
Authorization: Bearer <your API key>

# Include text, image and video:
GET /v1/models?output_modalities=all
GET /v1/models?output_modalities=image&availability=active
GET /v1/models?q=coder
GET /v1/models/dxr-coder-pro

The default list contains text models. Your key’s model allowlist applies to lists and detail lookups. List results are in data; a detail lookup returns one model. Metadata includes gateway endpoints, input/output modalities, configured limits, and pricing in integer nanoUSD strings. Text prices are per token; media prices are per output and size. Divide by 1,000,000,000 to obtain USD. Availability can be active, preview or unavailable. Preview pricing does not enable requests. Discovery is limited to 60 reads per minute per account.

Image & video API

Use the same bearer key with /v1/media/catalog to check activation and prices. Submit to /v1/media/jobs, then poll your jobs and download the completed asset within seven days.

POST https://api.deepxroute.com/v1/media/jobs
Authorization: Bearer <your API key>
Content-Type: application/json

{
  "idempotencyKey": "<new UUID for this generation>",
  "model": "uhub-lume-base",
  "size": "1024*1024",
  "prompt": "A lighthouse at dawn"
}

GET /v1/media/jobs/<job-id>
GET /v1/media/jobs/<job-id>/asset

Reuse the same submission UUID if a connection fails; changing the content requires a new UUID. A job under review holds credit until checked. For a five-second video, use uhub-reel-cine with size 1080x1920. See Models for currently offered variants and pricing.

Usage & billing API

Use /v1/key to check your key’s budget, expiry and model access. Usage reports default to the calling key. To read account-wide usage or the wallet balance, explicitly enable Allow account-wide billing read access when creating or managing the key.

GET https://api.deepxroute.com/v1/usage/report?start=2026-10-01&end=2026-11-01&groupBy=model
Authorization: Bearer <your API key>

GET /v1/usage/records?start=2026-10-01&end=2026-11-01&page=1
GET /v1/usage/export?start=2026-10-01&end=2026-11-01

# Requires account billing read access:
GET /v1/usage/report?scope=account&groupBy=key
GET /v1/usage/report?scope=account&groupBy=member
GET /v1/billing/balance

Replace the example dates with your reporting period. UTC start is inclusive and end is exclusive, with a maximum of 180 days. Omit both to use this month through today. Group by day, model, key, model-key or day-model-key. Team breakdowns also support member, day-member and model-member. Filter with kind, state, model, keyId and memberId. Lists return items, hasMore and page; increment page while hasMore is true.

Team owners, administrators and finance members can choose a member in Usage, group costs by member, and open that member’s individual requests. Removed members retain their historical attribution. Developers and viewers see only their own activity. API reports and CSV use immutable member_id values without member email addresses; copy an ID from a report to filter with memberId. Console activity retains its member ID even when its internal key is hidden. A member filter always narrows the caller’s existing access.

JSON amounts are integer strings in nanoUSD: divide by 1,000,000,000 to obtain USD. CSV amounts are exact USD decimals. Finished requests use their settlement date; pending and review requests use their start date. Holds in a report cover only its selected dates and filters. The wallet balance endpoint reports all current holds.

Individual records and CSV include requested_model, preset_id, preset_version and preset_slug. The requested model is the first model after applying preset defaults and request overrides. The record’s model is the last recorded model, and the billed model when completed. Preset attribution keeps the version admitted for that request, even after edits or archive. Open “Routing attribution” in Usage to inspect it. Reports do not contain saved prompts or tool definitions; requests without a preset have null preset fields.

Reports are limited to 60 reads per minute per account; CSV exports allow six per minute and up to 10,000 rows. Narrow the dates or filters if an export is too large. API keys cannot change account settings through these read endpoints.

Open usage reports or manage API keys.

Setup CLI

Our CLI package is being prepared for publication. Use the manual settings above for now. The unrelated npm package named deepx is not this service’s CLI.

Set up a team

  1. Open Teams, create a team and choose its payment region. The team starts with a separate USD wallet.
  2. Invite members with a role and optional USD spending and model limits. Share each expiring, single-use link privately. The recipient signs in and explicitly accepts; no email is sent.
  3. Choose the team in the workspace account selector before creating keys, adding credit or using models. Each tab keeps its own selection. Switching accounts reloads the workspace and clears unsaved drafts and one-time secrets.
  4. Create a team API key and use the same API endpoint and client examples above. The key carries its team identity; do not add an account-selection header to public API calls.

Owners and administrators manage shared supplier credentials. Developers manage their own keys and private outputs. Finance members manage the team’s billing and review team usage. Viewers see membership and their own historical usage.

Team and member limits count settled charges and all outstanding holds. Daily, weekly and monthly periods reset in UTC; weeks start Monday. These limits cover DeepXRoute wallet charges, while supplier-direct bills remain separate.

Restrict supplier access

In Teams, open Team settings to set the supplier list for everyone. Open a member’s Manage form, or an invitation, to set a narrower list. Choose all/inherited access, selected supplier IDs, or no suppliers. Confirm changes with your current password.

The team and member lists intersect. An empty list blocks dispatch; inherited access adds no restriction. Limits apply to API keys and console requests, platform routes, saved supplier keys and every fallback attempt. Request options cannot override them. Supplier IDs identify DeepXRoute routes, such as uhub; they do not identify or restrict downstream suppliers inside an aggregator. Find configured route IDs in the model’s provider details.

Images and videos currently use uhub. A queued job denied before submission fails and releases its hold. A text or media attempt already sent may finish and be charged. Removing supplier access does not delete historical usage, invoices or receipts. Privacy, retention and region guarantees need separate verified supplier policies.

Changing a member’s role or removing them revokes their existing inference and management credentials and unused invitations. Rejoining preserves prior usage and does not restore old keys. Owners must transfer ownership before leaving.

In the selected team’s Billing page, owners, administrators and finance members can update the buyer profile and download invoices, receipts, credit notes and transaction statements. Personal sign-in and optional MFA remain under Settings.

Transfer existing credit

Select the team, then open Billing · Transfer credit. Owners, administrators and finance members can move their own personal credit into the team. Only the owner can return team credit to their own personal account. Choose the direction and USD amount, review both accounts, then confirm with your current password. Held credit cannot move. This is an internal transfer, so no new payment or currency conversion is made.

If the result is uncertain, keep the saved reference. Check its status, retry the same transfer, or cancel that reference before starting another. Reloading this tab preserves recovery details; passwords are never saved. A cancellation that finds an already completed transfer shows its result.

Refunds can reclaim the original payment’s unspent credit wherever it moved. The purchaser remains responsible for any already-consumed portion, and disputes can pause affected accounts. Original invoices, receipts and credit notes stay with the purchaser. Transfers appear in transfer history and wallet statements. Nested project workspaces are not available yet.

Close a team and retain its records

Only the owner can close a team. In Teams, choose Review team closure. Finish active work, resolve held credit and settle any team debt first. Review the current balance, type the exact team name, accept ongoing refund and dispute responsibility, then confirm with your password. Closure is permanent.

The remaining USD balance returns to the closing owner’s personal wallet. All members lose access, credentials are revoked and supplier secrets are erased. An unpaid checkout may still complete; late captured credit also returns to the closing owner. Refunds reclaim unspent credit, and any already-consumed portion of the team’s purchases can leave the owner’s personal wallet in deficit.

If a response is lost, check closure status or retry the saved reference. No result yet does not cancel a pending closure. After closure, the owner can select the closed team to download its original invoices, receipts, credit notes and statements, review usage and request a buyer correction. Closed teams do not count toward the one-active-owned-team limit.

Choose your provider

Open a model in the model catalog to see its configured providers and build a request example. Choose one provider to keep the request there, or allow eligible providers with an optional first choice. A model with only one provider has no backup. Your model’s USD price stays the same across its providers.

# Check current provider IDs and capabilities first.
curl --fail-with-body https://api.deepxroute.com/v1/models/dxr-coder-pro \
  -H "Authorization: Bearer $DEEPXROUTE_API_KEY"

# Use only UHub; no automatic provider fallback.
curl --fail-with-body https://api.deepxroute.com/v1/chat/completions \
  -H "Authorization: Bearer $DEEPXROUTE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "dxr-coder-pro",
    "messages": [{ "role": "user", "content": "Hello" }],
    "max_completion_tokens": 256,
    "provider": { "only": ["uhub"], "allow_fallbacks": false }
  }'

Use IDs returned by the model lookup; provider availability may change. Preview pricing still needs activation, and your key’s model permissions, budget, expiry and wallet balance still apply. The same provider controls work with Chat Completions, Responses and Messages.

only and ignore
Allow or exclude provider IDs. Restrictions apply to every attempt; an empty only list permits none.
order
Try eligible providers in this order, followed by other eligible providers. Use only as well to restrict the complete list.
allow_fallbacks
Defaults to true. False limits the request to the first eligible provider. A fallback needs another compatible provider and a confirmed non-billable rejection.
require_parameters
True excludes providers without declared parameter capabilities and rejects unsupported request fields. Check supported_parameters in the model response; null means strict matching is unavailable.
max_price
Optional prompt and completion ceilings, in customer USD per million tokens. For example, 0.60 means US$0.60 per million input tokens. These are price ceilings, not total spending limits; use an API-key budget to limit spending.

Python’s OpenAI SDK accepts routing through extra_body={"provider": …}. The model page generates the right syntax for each language. Disable SDK retries: resubmitting a text POST creates a separate request.

What happens when a provider fails?

Fallback uses one wallet reservation and can try another provider only after a rejection confirmed as non-billable. It never replays a timeout, a server error, an interrupted response or an accepted stream. Uncertain usage keeps credit held for review; check Usage before sending a new request.

Keep x-request-id for support. x-dxr-provider and x-dxr-attempts identify the last responding provider and attempt count. Response headers alone do not confirm completed usage. Unknown providers, incompatible settings and unsupported policies return 400 before credit is reserved.

Supplier keys (BYOK) let you choose customer-owned credentials where configured. Their separate routing fee and saved fallback permission also apply.

Price/latency sorting, caching and data-retention or regional policy controls are not available yet. Unsupported provider fields such as sort, zdr and data_collection are rejected, not silently ignored.

Reuse a routing preset

A preset saves model choices, system instructions, generation defaults, provider routing and client-executed function tools. Create one in Presets, then reference it in any of the three text APIs. Presets belong to one personal or team account; the inference key must belong to that account.

  1. Create a preset. Choose a permanent reference such as code-review, a model and optional backups. Add instructions and defaults. Use IDs from Models; saving a preset does not activate pricing or run a model.
  2. Copy its request example. Select Chat Completions, Responses or Messages. Supply your key through DEEPXROUTE_API_KEY. Choose defaults supported by that API and the eligible models.
  3. Review and update. Each configuration save becomes the active version. Inspect or restore earlier configurations in version history. Existing admitted requests keep their original version.
curl --fail-with-body https://api.deepxroute.com/v1/chat/completions \
  -H "Authorization: Bearer $DEEPXROUTE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "model": "@preset/code-review",
  "messages": [
    {
      "role": "user",
      "content": "Review this function and explain any issues."
    }
  ],
  "max_completion_tokens": 256
}'

The example assumes you created code-review. It targets production and may spend wallet credit. Automatic SDK retries must stay off; each inference POST is a new request. Check held or uncertain usage before trying again.

Defaults and request overrides

Reference
Use model: "@preset/code-review", or preset: "@preset/code-review". To replace the saved model list, send an explicit model or ordered models array alongside preset. The shorthand model: "dxr-coder-fast@preset/code-review" selects that model only.
Parameters and prompt
Explicit request fields win. Saved system instructions apply only when the request has no native system or developer instructions. Unsupported protocol-specific fields produce an error before a credit hold.
Provider routing
A request’s provider object replaces the entire saved provider object. Account, team, member and key restrictions still apply. See the provider guide.
Function tools
Saved and request functions merge by name. A matching request definition replaces the saved function; new names append. An empty request tools array retains saved functions. Your application executes functions; server-side tools are unavailable.
Version attribution
Keep x-request-id, x-dxr-preset-id and x-dxr-preset-version. They identify the admitted configuration, including on streams. x-dxr-model identifies the selected public billing model; an upstream body may use its own model alias.

Ordered model backups

Presets support up to four distinct model IDs in attempt order. Unknown model IDs are rejected; known models that cannot serve the request may be skipped. Provider attempts and model backups share a maximum of eight attempts and one credit reservation sized for the largest eligible price envelope. Only the selected model’s measured usage is charged. Fallback requires a confirmed non-billable rejection; timeouts, server errors and accepted streams are never automatically replayed. provider.allow_fallbacks: false considers only the first requested model and permits at most one supplier attempt. If that model is ineligible, the request fails without trying another model.

Import and automate presets

In the editor, choose “Import an API request body”. Paste only the JSON body and select its API. The import saves configuration, strips transient conversation/input and stream settings, and never invokes inference. Importing into an existing preset creates a new active version. Saved prompts and definitions remain in history; do not paste secrets.

For automation, create a management credential with presets:read and, when needed, presets:write. These credentials manage configuration; use an inference key to invoke it. Team owners and administrators can edit; developers can read and invoke; finance and viewer roles cannot read saved prompts.

# Create a preset. Generate REQUEST_ID once, and keep it for a retry.
# MANAGEMENT_KEY must have presets:write permission.
curl --fail-with-body https://api.deepxroute.com/v1/presets \
  -H "Authorization: Bearer $MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"requestId":"'"$REQUEST_ID"'","slug":"code-review","name":"Code review","config":{"models":["dxr-coder-pro"],"parameters":{"max_tokens":256}}}'

# List saved presets (requires presets:read).
curl --fail-with-body https://api.deepxroute.com/v1/presets \
  -H "Authorization: Bearer $MANAGEMENT_KEY"

Use the current revision and a new requestId for each edit, archive or restore. Repeat the same request ID and payload only to recover an interrupted change. A replay returns the original receipt; read the preset again for its latest state. Native API imports use POST /v1/presets/:slug/chat/completions, /responses or /messages, with Idempotency-Key and, for an existing preset, an If-Match revision header.

Disable a preset to stop new invocations temporarily. Archive permanently to retire it; its reference remains reserved. There are 50 retained presets per account and 100 versions per preset. Use the OpenAPI document for complete schemas, error responses and version-management endpoints.

Use your own supplier keys

Bring your own key (BYOK) connects a supplier account you pay directly. Your apps still authenticate with a DeepXRoute API key; the supplier secret stays in your account’s encrypted storage.

  1. Open Supplier keys in API keys. Choose an available supplier, paste its key and set a descriptive label. If no supplier is configured, adding a key is unavailable.
  2. Choose primary or backup key order, priority, optional model and application API key limits, and expiry. Keep the default platform-credit block unless you want to permit full-price DeepXRoute capacity.
  3. Choose your account default. Automatic follows your saved key order. Supplier keys only stops when none can serve the request. Platform only uses ordinary DeepXRoute credit. Claude Code and Codex use this default without changing their configuration.
  4. Check the model’s fee and availability in Models, then make a request. Saving a key does not verify supplier access, activate pricing or add credit.

Choose primary and backup keys

Automatic mode uses this order, stopping as soon as a request succeeds:

  1. Primary supplier keys.
  2. Platform routes that satisfy every applicable saved spending policy.
  3. Backup supplier keys.

Within each supplier-key group, your provider order comes first, then lower key priority numbers. Supplier keys only skips the platform step; Platform only skips both supplier-key groups. Choosing Backup does not permit platform spending. Without that permission, backup keys follow primary keys directly.

All three steps share the eight-attempt limit. With allow_fallbacks: false, only the first eligible attempt runs; that may be a platform route if you only have backup keys and permit platform credit. An uncertain response stops the sequence for review.

Control where platform credit can be spent

Each key has a Platform credit in Automatic setting. Matching models means its model selection, or all models when unrestricted. Every choice respects its application API key limit.

  • Block all suppliers · matching models. The default keeps matching requests on saved supplier keys across all suppliers. Existing no-platform-credit settings keep this rule.
  • Block this supplier · matching models. Matching models must use your key on this supplier. Other models and other suppliers may use full-price platform credit.
  • Block this supplier · all models. This supplier cannot use platform credit, even outside the key’s model selection. Other suppliers may still use full-price platform credit.
  • Allow platform credit. This key adds no restriction to platform spending. Other saved keys can still block it.

Restrictions combine: an Allow setting cannot override another key’s block. To require your own keys everywhere, choose Supplier keys only. To restrict suppliers as well, use provider.only. A supplier-wide spending block never expands the models your key can use.

Separate applications with API key limits

Limit a supplier key to selected DeepXRoute API keys to keep applications or environments separate. Select keys by their labels and prefixes, never by pasting another secret. Both the model and API key limits must match. Without an API key limit, all current and future application keys and the console playground can use it.

Unselected applications and the playground skip a restricted supplier key and its fallback preference. In Automatic mode they may use platform credit. Choose Supplier keys only to stop when no matching supplier key is available. Revoking an application key does not transfer its access to a replacement; edit the supplier key to select the replacement explicitly.

Choose credentials for one request

An explicit choice overrides the account default. Send byok to require a saved supplier key or platform to use DeepXRoute capacity. Omit the field, or use auto, to follow your account default. Do not put a supplier secret or URL in the request body.

curl https://api.deepxroute.com/v1/chat/completions \
  -H "Authorization: Bearer $DEEPXROUTE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "dxr-coder-pro",
    "provider": { "credentials": "byok", "allow_fallbacks": false },
    "messages": [{ "role": "user", "content": "Hello" }],
    "max_completion_tokens": 64
  }'

Use an enabled model returned by the catalog. The same credential controls work with Chat Completions, Responses and Messages. The example makes at most one supplier attempt; a successful key check alone does not guarantee that inference is available.

Understand the two bills

Your supplier charges its own usage to your supplier account. DeepXRoute charges a separate fee based on its listed model token prices and the configured fee percentage. For illustration, a 5% fee on US$1.00 of listed usage is US$0.05, plus whatever your supplier charges. Check the current fee rather than relying on this example.

A supplier-key-only request reserves the maximum DeepXRoute fee, then settles the fee for reported usage. If platform fallback is permitted, the reservation covers the full model price. A successful supplier-key request still settles only its fee; a platform attempt settles the full model price. Key budgets limit DeepXRoute charges and holds, not your separate supplier bill.

Usage labels BYOK fees and separates them from platform charges. CSV exports include the fee version and credential reference. Supplier invoices come from the supplier; DeepXRoute receipts and invoices cover your prepaid credit purchases in Billing.

Fallback and recovery

  • Automatic checks each platform route against the saved spending policies. Disabled and expired keys keep their policies. When a supplier has no unrevoked applicable key, its last applicable revoked policy remains. Removing or excluding a supplier does not erase its policy.
  • To return to normal platform usage after revoking a key, explicitly select Platform only as your account default or in the request. API key limits always scope a policy to the selected apps; a supplier-wide block also covers models outside the key’s model selection.
  • At most eight attempts share one reservation. Fallback only follows a confirmed, configured non-billable rejection. Timeouts, incomplete streams and uncertain responses keep credit held for review. Do not enable automatic SDK retries.
  • Replacing a key preserves its policy. After a lost response, reload the list and check the secret version before trying again. Revocation erases the saved secret; already authorized calls may finish using it.
  • Retain the request ID, x-dxr-provider, x-dxr-attempts and x-dxr-billing-mode when contacting support. Never include either key’s secret.

Provider routing controls explain provider restrictions, optional parameters and catalog-price ceilings.

Automate key management

Create a separate management credential for a backend service or CI job. Choose inference-key permissions for application access and usage, supplier-key permissions for BYOK, and preset permissions for saved routing configurations. Read-only access is enough for inventory. Management credentials cannot run models or access payments, invoices or sign-in settings.

Store the credential in your server’s secret manager as DEEPXROUTE_MANAGEMENT_KEY. It must use the Bearer header. Ordinary inference keys and the alternative x-api-key header do not authorize management requests.

Manage inference keys

# Read permission: list keys, including revoked/expired records.
curl 'https://api.deepxroute.com/v1/keys?page=1' \
  -H "Authorization: Bearer $DEEPXROUTE_MANAGEMENT_KEY"

# Read/write permission: create a key with a US$10 monthly limit.
# Generate a UUID once and replace YOUR_SAVED_UUID; retain it for retries.
curl https://api.deepxroute.com/v1/keys \
  -H "Authorization: Bearer $DEEPXROUTE_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "requestId": "YOUR_SAVED_UUID",
    "name": "Production app",
    "budgetNanoUsd": "10000000000",
    "budgetPeriod": "monthly",
    "allowedModels": ["dxr-coder-pro"],
    "billingRead": false
  }'

Save the returned key in the application’s secret manager. After a timeout, retry the same creation UUID and settings with the same management credential to recover the same key. Changing settings under the same UUID returns a conflict. List/get responses never include secrets. A new UUID creates a separate key.

# Read current metadata and revision first.
GET /v1/keys/KEY_ID

# Keep omitted settings; send the latest revision to avoid stale writes.
PATCH /v1/keys/KEY_ID
{"revision":1,"budgetNanoUsd":"5000000000"}

# Revoke model access; usage history remains available.
DELETE /v1/keys/KEY_ID

Limits are integer nanoUSD: 1 USD = 1,000,000,000 nanoUSD. A null budget means no key limit; zero prevents new spending. Every inference key shares the account wallet. Creating keys does not add credit or activate provisional models. Ten unrevoked inference keys and five active management credentials are allowed per account.

Rotate credentials by creating and testing a replacement, updating your automation, then revoking the old credential. Revoking a management credential does not revoke the inference or supplier keys it managed. Revoke those separately when needed; previously accepted requests can still finish and settle.

Manage supplier keys and routing

Supplier permissions start off. Choose read access to inspect saved keys, configured suppliers and routing defaults. Choose read/write to add, replace or revoke supplier keys, change their model and application limits, and control platform fallback. This also permits changing the account default to full-price platform billing. Existing management credentials do not gain these permissions automatically.

Store your supplier secret in your automation’s secret manager. The API accepts it when saving or replacing a key, then returns metadata only. Read the configured supplier IDs first; a successful save does not confirm that the supplier accepts the key. See the supplier-key guide for fees, application limits and fallback behavior.

# Supplier read permission: configured suppliers, fee and account default.
curl https://api.deepxroute.com/v1/provider-keys/settings \
  -H "Authorization: Bearer $DEEPXROUTE_MANAGEMENT_KEY"

# Supplier write permission: save a key without platform fallback.
# Replace placeholders in server automation; retain the UUID for retries.
curl https://api.deepxroute.com/v1/provider-keys \
  -H "Authorization: Bearer $DEEPXROUTE_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "requestId": "YOUR_SAVED_UUID",
    "provider": "YOUR_PROVIDER_ID",
    "name": "Production supplier",
    "secret": "YOUR_SUPPLIER_KEY",
    "allowPlatformFallback": false
  }'

Keep this creation UUID and the exact settings after a timeout. Unlike inference-key creation, supplier-key retry identity is shared across your account, so replacing the management credential does not create another supplier key. Identical retries return metadata while the original key is unchanged. Changed settings, any edit or revocation cause a conflict; read the saved record before deciding what to do.

# Supplier read permission: includes current revision and secret_version.
GET /v1/provider-keys/PROVIDER_KEY_ID

# Supplier write permission: restrict to an existing application API key.
PATCH /v1/provider-keys/PROVIDER_KEY_ID
{"revision":1,"allowedApiKeys":["APPLICATION_KEY_UUID"]}

# Replace the secret; preserve its model/app limits and fallback setting.
POST /v1/provider-keys/PROVIDER_KEY_ID/rotate
{"revision":2,"secret":"YOUR_REPLACEMENT_SUPPLIER_KEY"}

# Erase the stored secret; preserve policy and usage history.
DELETE /v1/provider-keys/PROVIDER_KEY_ID

Use the latest revision for each update or replacement. Omitted fields stay unchanged; null removes a model or application limit. After an interrupted replacement, read the revision and secret version before retrying. Revoking a supplier key does not grant platform fallback, and calls already authorized may finish. Read-only automation cannot change keys or routing preferences.

Preset permissions start off and include access to retained prompts and function definitions when granted. See preset automation for creation, imports, version history and restore examples.

Management requests are limited to 60 per minute per account. The OpenAPI document includes schemas, pagination, permissions and error responses.

Secure your API keys

Open Key security in your console. Check the selected personal or team account before reviewing keys or changing its policy. Owners and administrators manage the account; developers manage their own inference keys. Finance and viewer roles cannot access credentials.

  1. Review access. Filter inference or management keys by name, prefix, owner, state or review category. Missing limits and expiry are review prompts, not proof of misuse. Unknown activity means historical authentication evidence is incomplete. Export the filtered CSV for a complete review; it includes up to 10,000 matching keys and never includes secrets.
  2. Apply a bounded change. Select the keys you intend to change, review their names and prefixes, then confirm your password. Selection clears when pages or filters change. Disable is reversible; revoke is permanent. Setting missing limits affects inference keys only and preserves existing limits. An enabled authenticator must be verified; MFA remains optional.
  3. Restrict API access when ready. Under Account policy, add your application servers’ fixed public egress IPs or CIDR ranges, including IPv6 if used. The observed console connection may be your laptop’s address, not your server’s. Check the egress address with your hosting/network configuration. Dynamic CI runners may need fixed egress before using an allowlist. Do not allow a whole public network or a shared CDN address to make a failed request pass.

Expiry and network rules

A maximum lifetime of 1–366 days applies from the key’s original creation to its explicit expiry. Existing keys with no expiry or an excessive lifetime are denied while the limit is enabled; settings do not silently rewrite their expiry. Update expiry in API keys, or replace a credential that cannot meet the policy.

Network rules apply to existing and new inference and management keys on all public API routes. Test from the actual application server after saving. Unsent or queued work may be canceled when its source becomes disallowed or is unknown; already dispatched work still settles once. A 401 can indicate a disabled, revoked or expired key. A 403 can indicate network, lifetime or other access restrictions; review the returned error before retrying.

Recover without losing console access

API network and lifetime restrictions do not restrict console sign-in. If a server is blocked, sign in, select the correct account and open Account policy. Correct the rules, or clear the network list and save to remove that restriction. Leave maximum lifetime blank and save to remove the account lifetime limit. Other credential and spending restrictions remain in effect.

If a save is interrupted, keep the page open and choose “Retry same change” or “Retry same policy change”. The console retains the same operation reference and values in memory so recovery does not apply a second change. Do not refresh or close an unconfirmed change. After a revision conflict, load the latest policy for comparison, then replace the draft and reapply the changes you still want. Never paste passwords or keys into a support message.