Webhook endpoints are an Enterprise feature (the
webhookEndpointsEnabled plan flag). On other plans the API answers 403 and the settings page shows an upgrade state. Self-hosted enterprise licenses include it.The model
An endpoint belongs to your organization and carries:
Manage endpoints under AI Gateway > Webhooks (
/settings/gateway/webhooks) or over REST with an organization API key:
201 response carries the endpoint plus secret, returned only this once. Store it where your receiver can verify signatures.
The envelope
Every delivery is one POST with a JSON body of the form{"batch": [envelope, ...]}. Each envelope is one real-world occurrence:
idis the idempotency key: stable across retries and replays. Dedup on it. For spend events it is the gateway request id with a type suffix (<gateway_request_id>:completed,<gateway_request_id>:settled), so the settled and completed events for one request never collide in your dedup layer whiledata.gateway_request_idjoins them.createdis when the event occurred, never when it was delivered. Late deliveries land in the right period.schema_versionversions thedatapayload per type.
max_batch_size envelopes, possibly of mixed types within your subscription. Ordering is best-effort: rely on created and your own dedup, not arrival order.
Event catalog
GET /api/webhooks/v1/event-types returns the live catalog. Types are grouped by family (the first dotted segment), which is also what the settings UI renders as checkbox groups and what the gateway.* wildcard matches.
Family: gateway
The spend payloads (
gateway.request.*) are documented field by field on Billing and spend events. The governance payloads:
gateway.budget.threshold_crossed and gateway.budget.breached (data):
bucket_scope_id is <anchor_id>:<end_user_id> and end_user_id is set, so your platform can tell “this user’s cap” from “the tenant cap”.
virtual_key_id and anchor_project_id name the key and the project the budget targets, as their own fields. virtual_key_id is set for a virtual-key budget and for an attributed-user template (where it is the anchor); anchor_project_id is set for a project-scoped budget. Read those rather than splitting bucket_scope_id, which you cannot split reliably when an end-user id contains a colon.
Every enum on these payloads is
lower_snake_case (scope_type, window, on_breach), matching the rest of the wire.gateway.virtual_key.* (data):
Verifying signatures
Every delivery carries:Rotating the signing secret
roll-secret returns a new secret and keeps the old one valid for 24 hours. For that window every delivery is signed with both, so there is no coordinated deploy and no gap:
- Call
roll-secretand store the new value. - Deploy it to your receiver any time in the next 24 hours. Deliveries keep verifying under the old secret until you do.
- After the window the old secret stops being signed with and stops verifying.
Delivery, retries, and auto-disable
Your receiver acks with any2xx. The delivery classifier:
5xx,429, and408are retryable. ARetry-Afterheader on those is honored as a floor on the next attempt.- Any other non-2xx status is terminal for that batch: retrying a misconfigured endpoint just spams it. Redirects are never followed, so a
3xxis terminal too.
disabled with disabled_reason: "auto_failures_72h" and delivery stops. Sources keep accruing the whole time: disabling delivery never loses events.
To recover:
- Fix the receiver.
- Re-enable:
PATCH /endpoints/:id {"status": "active"}. - Re-enabling does not re-send the gap. Replay it explicitly: for spend events,
POST /api/gateway/v1/spend-events/replaywith the gap window and this endpoint’s id.
Delivery controls
Three per-endpoint knobs, validated server-side against fixed bounds; out-of-range values are rejected with the bound named in the error:Health and the lag number
GET /endpoints/:id/health:
oldest_undelivered_age_ms: the age of the oldest envelope still buffered or retrying for this endpoint. It is your feed’s staleness, the number that tells a billing operator how far behind their invoice data could be. Zero or small is healthy; growing means your receiver is failing or slow. sends_per_minute and success_rate aggregate the last hour; p95_latency_ms is sampled over the same window. dlq_depth counts dead-lettered batches awaiting manual attention.
The delivery log
GET /endpoints/:id/deliveries lists recent attempts, newest first: the attempt number, envelope count, outcome, your endpoint’s HTTP status, latency, and the error text when transport failed. Your receiver’s responses are recorded, so debugging a rejecting endpoint starts here rather than in your own logs.
The list is cursor-paginated on (fired_at, id) at 25 rows by default (max 200), and the response carries next_cursor when more remain. Cursors rather than offsets because a busy endpoint writes new attempts while you page: an offset walk would show you the same row twice and skip another. Delivery log rows are retained for 30 days.
Test fire
POST /endpoints/:id/test sends one signed test.ping envelope through the full delivery path, including SSRF checks and signing, plus an X-LangWatch-Test-Fire: true header so your receiver can tell it apart. The route answers 200 whenever the test itself ran; read data.delivered and data.response_status for what your receiver did. Test fires appear in the delivery log too.
The events log
GET /api/webhooks/v1/events?type=&from=&to=&cursor=&limit= is the organization’s emitted-events log: cursor-paged, newest first, filterable by type and created range (unix milliseconds). Webhooks are push over this log, never the only copy of it, so a consumer that missed deliveries can list what was emitted and recover.
GET /api/webhooks/v1/events/{id} reads one event back by the id its envelope carried. A 404 means the log cannot answer for that id, and deliberately does not say which reason applies.
Which families the log holds
The log serves the request families only:
The governance families are delivered to your endpoints exactly like the request families, but they are not retained in a queryable log, so they cannot be listed, read by id, or replayed. If you need a durable record of budget and virtual-key events, persist them from your receiver when they arrive. A request for a type this log does not hold returns an empty page rather than an error, so a client can probe for new families without breaking.
For billing reconciliation, do not reconcile against this log: read the spend ledger surfaces instead (
spend-summaries and spend-events), which include settled rows and carry the 13-month retention contract. The events log is for delivery recovery and debugging.
What events never carry
No prompts, no completions, no conversation content, ever. Envelopes carry ids, quantities, classes, states, and your own metadata echo. If you need content downstream, that is the traces API, a separate surface with its own access control.See also
- Billing and spend events: the spend payloads, the money contract, reconciliation, replay.
- Metering and rebilling your customers: the end-to-end integration cookbook.
- Self-hosting webhooks: egress policy, local receivers, license flag.
- Budgets: what threshold_crossed and breached mean and when they fire.