Provider access stays separate from application control.
01
Translate the boundary deliberately
Applications use the gateway's conventional /v1 path while the provider adapter targets DeepSeek's documented API base. That translation stays explicit so a path difference does not become a silent routing failure.
02
Keep isolation identifiers non-personal
DeepSeek documents a user identifier for scheduling and cache isolation and warns against personal information. The gateway's own scoped principal remains the source of internal attribution; provider-facing identifiers must stay non-personal and tenant-safe.
03
Account for cached and reasoning tokens
Provider usage can distinguish cache hits, cache misses, and reasoning tokens. Gateway receipts retain the normalized usage and cost evidence needed for budgets and reconciliation rather than rounding a low-cost request down to zero.
Current shared controls
Status determines what can be configured.
Write-only, encrypted BYOK for implemented provider connections Stable model aliases and protocol-eligible route targets Organization and key budgets, RPM, TPM, and concurrency hard limits Observe, Shadow, Enforce, reason codes, and metadata-only evidence
Beta connections require customer validation against the exact model, payload, streaming mode, region, and provider account before production use.
Applications keep a stable gateway URL and model alias while an administrator changes eligible provider accounts and models.
Implemented boundary
Only documented protocols become eligible.
Choose DeepSeek, enter the write-only API key, verify the catalog, and let the gateway safely translate its /v1 client boundary to DeepSeek's current unversioned API base.
POST /v1/chat/completions GET /models connection test
Compatibility is bounded to the provider's current published interface. Review the provider documentation before approving a production model.