Docs · Webhooks

Webhooks

Events for every movement and every decision.

Designed. Webhooks, GET /v1/events and the event names below are designed. Access and security events are already written to the audit record; see Core concepts.

Every change becomes an event. Read them with GET /v1/events, or receive them at your webhook endpoints.

Deliveries	One delivery per event per endpoint.
Attempts	Every attempt is kept: status, timing, signing-key version.
Replays	Replay any delivery. Replays are linked to the original.

Illustrative example

{
  "id": "evt_01J9b",
  "type": "payment.captured",
  "schema_version": "2026-10",
  "data": {
    "payment_id": "pay_01J9",
    "ticket_id": "tkt_01J9"
  }
}

Every delivery is signed. Retries back off. Each event has an id you can use to deduplicate.

An event, from the change to your endpoint Designed. Every change becomes an event. Each delivery is signed, retried with backoff and can be replayed.

Steps in text

insimbi API and record: A payment is captured and written to the record
insimbi API and record to Events and deliveries: Emit payment.captured with an event id and schema_version
Events and deliveries to Your webhook endpoint: Deliver the event, signed. One delivery per event per endpoint.
Your webhook endpoint to Events and deliveries: No 2xx in time: the attempt is kept with its status and timing
Events and deliveries to Your webhook endpoint: Retry with backoff, signed with the current signing-key version
Your webhook endpoint to Events and deliveries: 2xx: delivered
Your webhook endpoint: Deduplicate on the event id before acting
Your team or service to Events and deliveries: GET /v1/webhooks/{webhook_id}/deliveries/{delivery_id}/attempts
Your team or service to Events and deliveries: POST .../replays to replay a delivery. The replay is linked to the original.
Your team or service to Events and deliveries: GET /v1/events to read every event with cursor pagination