New submission events, pushed to your registered endpoint
Hedge POSTs this message to each webhook endpoint your brokerage has registered (broker portal → Settings → Webhooks, admins only) whenever a submission gains newly-visible events; the SAME event objects, vocabulary and visibility rules as GET /broker/submissions/{submission_id}/events, delivered within about a minute of becoming visible. An endpoint receives events from its creation onward; history is not replayed.
Verifying. Every delivery is signed with your endpoint's whsec_ secret (shown exactly once at creation; rotate by revoking and re-creating). Headers are the standard-webhooks / svix scheme, verifiable with any svix SDK:
- svix-id; the delivery id, STABLE across every retry and manual redelivery: your idempotency key.
- svix-timestamp; unix seconds; reject stale timestamps (±5 minutes is the conventional tolerance).
- svix-signature; v1, + base64(HMAC-SHA256(secret, {id}.{timestamp}.{body})) over the exact bytes received.
Delivery semantics. At-least-once: dedupe on svix-id. Within one submission, deliveries arrive in order; across submissions there is no ordering guarantee. An event's (id, type) pair can arrive AGAIN with an upgraded type; e.g. a status_changed later re-delivered as quote_received once the quote is relayed to you; so treat (id, type) as the event identity; deduping webhook events by id alone will drop quote arrivals. (The polling feed has no such re-emission; this is push-only behavior, and it is how a relay that happens hours after the underlying status row is still pushed to you.)
Acknowledging. Respond 2xx within 10 seconds; the body is ignored. Redirects are treated as failures. Anything else is retried with backoff for up to 8 attempts over 24 hours; the delivery is then parked (re-send it from the portal's delivery log). Repeated exhausted deliveries auto-disable the endpoint; a successful test-send from the portal re-enables it and queued events resume.
A ping message ({"type": "ping", ...}, same signature scheme) is sent by the portal's test button; acknowledge it like any other delivery.
Filtering. An endpoint's optional event_types filter names the event types it wants (market_attached, quote_received, status_changed, declined, withdrawn, blocked, bound) and may include message to also receive submission.message deliveries (below). No filter = everything.
Payload
Response
Acknowledge with any 2xx within 10 seconds; response body is ignored.
Changes
Webhooks have no change history: a webhook is keyed by its event name rather than a path and method, so no recorded change can name it.