Call types

A call type is a label for a workload (e.g. support-reply-draft, code-review). Each call type carries its own configuration — model pin, router mode, compression mode, fallbacks, provider preferences — so you tune behavior per workload instead of per request.

Attach one with the call_type field (or the X-UR-Call-Type header; the body wins):

{
  "model": "openai/gpt-5-mini",
  "messages": [{ "role": "user", "content": "…" }],
  "call_type": "support-reply-draft"
}

The first time a call type is used it is auto-created — call types emerge from usage. You can also manage them programmatically via /v1/call-types or in the dashboard.

Effective-config precedence

Every tunable resolves through one documented five-level chain. The first layer that defines a field wins:

1. Request — fields on the request body (or X-UR-* headers).
2. Per-key defaults — an API key's config_defaults.
3. Call-type config — the call type's active config version.
4. Workspace defaults — the workspace's default config version.
5. System defaults — the built-in defaults (compression off, router off, provider sort price, …). model has no system default — a request with no model and no configured pin is a 400 invalid_request.

The winning layer per field is recorded on the request, so the dashboard can show the effective value, its source, and how often requests override it.

Config as versions

Every config change is an immutable new version plus a repoint plus a config-version bump, committed in one transaction. Rollback is re-pointing to a prior version — nothing is edited in place. The gateway reads config through a 5-second versioned cache, so any change (a new pin, a revoke) is visible within one cache window with no distributed invalidation.