Skip to main content
The simplified, key-first surface for Routing Studio. The customer never sees a “preference” object — the server find-or-creates a hidden per-key preference under the hood and ensures the binding row points at it. Reach for this endpoint when you’re tuning a single API key. Reach for /api/v1/routing-preferences when you want a shared rule set that spans many keys or acts as a team default.

Authentication

Requires a Bearer token with the billing API key scope and access to the key (caller owns it, or has access through the active org).

GET

Read the per-key rules and the resolved binding state.

Response

  • active: true — these rules drive completions on this key right now.
  • active: false — the key inherits a default (or is bound to a shared preference); rules are still editable but inactive until saved or until the shared binding is cleared.
  • shared_binding — populated when the key is bound to a shared preference instead of its hidden row. Render the shared rules read-only and offer an “Override on this key” button.

PUT

Replace the per-key rules / examples / overrides. The route find-or-creates the hidden preference and ensures the binding points at it.
object[]
Up to 50 rules. Same shape as routing-preferences.
object[]
Up to 30 few-shot examples.
object
Per-mode confidence-floor overrides.

DELETE

Clear the per-key rules: drops the binding so the resolution cascade falls back to org default → user default → none, and deletes the hidden preference row. Existing bindings to a non-hidden (shared) preference are left alone.

Errors

  • 400 routing_preference_invalid — Validation failure (vendor name, uncompilable regex, etc.).
  • 404 not_found — Key doesn’t exist, is revoked, or isn’t accessible to the caller.