/typesafe prefix, so the official TypeSafe SDKs work by pointing their base URL at Bifrost. You keep the SDK’s question builders, retries, and types - and gain Bifrost’s key management, governance, logging, and cost tracking.
Endpoints
Python SDK
Both SDKs readTYPESAFE_BASE_URL from the environment, so the zero-code-change setup is:
typesafe-sdk package):
JavaScript / TypeScript SDK
@typesafe-ai/sdk takes baseURL (falls back to TYPESAFE_BASE_URL):
Authentication
The SDK’sAuthorization: Bearer header authenticates the request to Bifrost when Bifrost authentication is enabled. Configure the TypeSafe provider with its upstream keys - Bifrost selects and injects the provider key on the upstream call, so clients can use Bifrost virtual keys instead of raw TypeSafe keys.
Using a virtual key - pass it as the SDK’s API key; governance (budgets, rate limits, model restrictions) applies per key:
Behavior Notes
- Success responses are shape-compatible with TypeSafe’s own API: native
answerswithnoul/choice/scorevalue fields andinput_tokens/output_tokensusage. Bytes are identical only on the raw-response passthrough path; otherwise the response is rebuilt and re-encoded, preserving the shape but not exact JSON byte ordering. - Models: bare IDs (
jev-1.13.0,jev-latest,jev-preview) work exactly as upstream;typesafe/-prefixed IDs are additionally accepted. - Errors: returned in TypeSafe’s native shape (
{"detail": {"error_type", "message"}}) with upstream status codes (401, 422, 429, 529) preserved, so SDK exception parsing works unchanged. Requests rejected by Bifrost’s local validation return400where TypeSafe’s own validation would return422. - Retries: Bifrost retries 429 and 529 with backoff per the provider’s
network_configin addition to any SDK-side retry policy.
For provider-routed access with fallbacks and Bifrost’s normalized response shape, use
POST /v1/decisions instead - same questions, kind instead of type, and a unified value per answer.
