Instrumentation & observability
Request IDs, rate-limit headers, usage stats, and how B2A attributes agent traffic.
Everything B2A exposes to help you (or your agent) observe and debug API usage.
Request IDs
Every response carries an X-Request-ID header, and every error body includes
the same request_id. Quote it when reporting an issue — it links directly to
our structured logs.
Rate-limit headers
Every authenticated response includes:
| Header | Meaning |
|---|---|
X-RateLimit-Limit | Requests allowed per minute for your key |
X-RateLimit-Remaining | Remaining requests in the current window |
X-RateLimit-Reset | Unix time when the window resets |
Retry-After | Only on 429 — seconds to wait before retrying |
Agents should treat 429 + Retry-After as a normal backoff signal, not an
error to surface to the user.
Your usage stats
GET /v1/keys/{key}/stats (authenticated with the same key) returns request
counts for today and in total, plus your top endpoints. Useful for agents that
self-monitor their budget against the daily cap.
Surface and tool tagging
Calls made through the MCP server are tagged with X-B2A-Surface: mcp and
X-B2A-Tool: <tool_name> automatically. If you build a custom client and want
your traffic classified correctly (e.g. to appear as MCP-style usage in our
adoption metrics), you may send the same headers — they are optional and never
affect the response.
Identifying your agent
Pass an agent label when creating a key (POST /v1/keys,
{"agent": "my-agent-name"} — also available on the b2a_get_key MCP tool).
The label is attached to your key’s metadata and helps us prioritize
compatibility work for the agent stacks that actually use B2A. Anonymous — no
account or contact information involved.
Outbound link attribution
Booking links returned by the API carry utm_source=b2a&utm_medium=ai_agent
query parameters. Keep them intact when presenting links to users: they let the
downstream booking site recognize agent-originated traffic, which is what keeps
this API free to use.