Skip to main content
Orgo can push event notifications to a URL you control. Subscribe to any subset of 18 event types, register an HTTPS endpoint, and Orgo delivers a signed JSON POST every time a matching event happens. This page is the reference. For a complete walkthrough — including idempotent handling and replay — see Handle webhooks.

Available events

Every event ships with the full entity snapshot (object) and, for updates, a diff (previous_attributes). The complete payload schemas are in the Webhooks section of the playground.

Subscribing

Create a subscription via the API or in the admin UI under Settings → Developers → Webhooks.
The secret is yours to choose — a 32-byte random string is standard. Orgo uses it to sign each delivery so you can verify the payload came from Orgo.

Payload envelope

Every delivery, regardless of event type, has the same outer shape (Stripe-inspired). Only the object and previous_attributes differ per event.
The OpenAPI spec declares a Webhook.<EventName> schema for each event type (e.g. Webhook.UserCreated) — use these in your typed client for autocomplete and validation.

Delivery headers


Authenticating the sender

Set a secret on the subscription and every delivery carries X-Webhook-Signature in this shape:
The timestamp is inside the signed string, so it cannot be edited without invalidating v1. That is what lets you reject a captured delivery replayed later. Verify against the raw body. A body that has been parsed and re-serialized is a different byte string and will not match.
Respond 401 and log the delivery ID when verification fails. Orgo treats that as a failed delivery and retries it, which is the behavior you want if the failure is your own misconfiguration. Each retry is signed at the moment it is sent, so the same delivery ID can arrive with different t and v1 values. Deduplicate on the payload id or X-Webhook-Delivery, never on the signature.
This format shipped in August 2026 and replaced a short non-keyed checksum. There is no compatibility header: a receiver comparing the old value must move to the recipe above.

Idempotency

Orgo may deliver the same event twice — retries on transient failures, network races on at-least-once delivery. Your handler must be safe to call repeatedly with the same payload. The simplest pattern: track processed deliveries by payload["id"].
Keep delivery IDs for at least 30 days. If you can, insert the dedup row in the same transaction as the side effect — that closes a window where a crash mid-handler leaves the dedup row but not the effect.

Retry behavior

The subscription itself is not automatically deactivated on repeated failures — your own monitoring should watch for high failure rates.

Delivery logs and replay

Every delivery attempt — success or failure — is logged for ~90 days. To list:
For each failed delivery, the original payload is included — replay it locally without needing Orgo to re-deliver.

Testing

Before going live, send a synthetic event to your endpoint:
The synthetic payload uses fixture data (not real user data) but carries the same headers and shape your handler will see in production. Use this in CI to validate end-to-end delivery.

Webhook events

Each event type is declared as a “webhook” in the OpenAPI spec — Mintlify renders them in the playground under a Webhooks section. Click into any event to see its full payload schema, headers, and example. The 18 events are listed at the top of this page.