Skip to main content
All Majordomo-specific behavior is controlled via HTTP headers. Standard provider SDK headers (Authorization, Content-Type, etc.) pass through unchanged.

Request headers

Provider inference

If X-Majordomo-Provider is not set, the gateway infers the provider: Set the header explicitly when your path doesn’t match the defaults, or when routing the same path to multiple providers.

Metadata headers

Any header prefixed with X-Majordomo- is stored as metadata on the request log, except the reserved headers that carry dedicated behavior: X-Majordomo-Key, X-Majordomo-Provider, X-Majordomo-Provider-Alias, X-Majordomo-Client, and the agent run tracking headers (X-Majordomo-Trace-Id, X-Majordomo-Span-Path, X-Majordomo-Span-Name).
Metadata is stored in the raw_metadata JSONB column on llm_requests. Keys can be promoted to the indexed_metadata column (GIN-indexed) via the dashboard for fast @> queries. Naming convention: The X-Majordomo- prefix is stripped and the remainder is stored as-is. X-Majordomo-Feature becomes Feature in the metadata map. No schema changes required. New keys are stored immediately. You can add metadata dimensions without touching the database. See Cost Attribution for query examples.

Agent run tracking

When one logical task — a conversation or an agent/workflow run — makes several LLM calls, these headers group those calls into a single run so the dashboard can show a rolled-up cost and a nested waterfall instead of unrelated requests. They are reserved (consumed by the gateway, not stored in raw_metadata) and stored as first-class columns on llm_requests. Graceful degradation: a trace id alone gives a flat run rollup (all the run’s calls + total cost); adding a span path gives the nested waterfall (which tool/agent step drove which calls, and what each cost). No SDK is required — any client that can set headers works.
See Agent Run Tracking for the full walkthrough.

Full example

Header forwarding

Headers prefixed with X-Majordomo- are not forwarded to upstream providers. They are consumed by the gateway and stripped before the request is proxied. All other headers (including custom X-* headers your provider supports) are forwarded as-is.