Skip to main content
Webhooks let your systems react to Tybrite events as they happen, without polling for them. When an order is paid, a payment fails, or a customer signs up, Tybrite sends an HTTP POST to your registered endpoint containing the full event payload.
Dashboard: You can manage webhook endpoints directly from Settings → Webhooks in your Tybrite dashboard, or programmatically via the API and SDK.
Webhooks are for reacting to events on your own infrastructure. If you would rather the reaction ran on ours — a validated recipe or a small function, with no server to host or endpoint to secure — see Automations. Both fire off the same events.

Quick start

1. Create an endpoint
2. Verify + handle deliveries
3. Send a test event

Event catalogue

All events follow the same envelope shape — only type and data.object vary.

Orders

Payments

Customers

Inventory & catalog

Cart & checkout

Gift cards

Promotions

Pricing

Dynamic-pricing rules change what every shopper pays without touching a product record, so a cached price is stale the moment one of these fires.

Content & collections

Deletion & restore

A deleted record has left the API: it no longer appears in any list, cannot be fetched by id, and stops taking effect — a deleted promotion stops discounting, a deleted product cannot be bought. Every deletion carries the record’s id and name, plus deleted_at and restorable_until. Deleting is reversible for 90 days, so each of these has a matching .restored event. restorable_until marks when that window closes, which supports either handling: removing your copy immediately and rebuilding it if a restore arrives, or holding it until the window has passed.

Visibility

A category that is switched off is filtered out of every catalog read, so it disappears from a storefront exactly as a deleted one would. Categories cannot be deleted — they are a fixed set a merchant enables or disables — so these are the only lifecycle events they produce, and they are what keeps navigation, a category strip, or any layout built from the taxonomy in step.

Store lifecycle & configuration

Feature availability

The Content & collections, Store lifecycle, and Feature availability events describe a store growing rather than a single transaction, which is what an automation tool listens to when it keeps a storefront in step with the store — adding a promo banner as a promotion goes live, a reviews block when the first reviews are approved, or a “shop by collection” row when a collection becomes homepage-eligible. See the automated workflows guide.

Catalog sync & syndication

Wholesale (B2B)

For stores with wholesale enabled, the B2B lifecycle also emits events: b2b.rfq.created, b2b.quote.sent / .accepted / .rejected, b2b.po.issued / .confirmed / .fulfilled, and b2b.invoice.issued / .paid / .overdue.

Event payload shape

Every event uses a consistent envelope:
previous_attributes is present on update events and contains only the fields that changed — useful for transition-based logic (e.g. “did payment_status just flip to paid?”).

Signature verification

Every delivery carries:
The signed string is ${timestamp}.${raw_request_body}. The secret is the signing_secret returned when the endpoint was created (per-endpoint, not the store HMAC secret).
The signature covers the raw body. JSON parsers may reformat whitespace or key ordering, producing a different byte sequence that fails verification, so the raw bytes have to be captured before parsing.
Serverless function example:
Next.js App Router example:

Delivery contract

A handler that has not returned 2xx within 30 seconds is treated as a failed delivery and retried, so heavy processing belongs on a queue rather than inline in the response path.

Idempotency

Because delivery is at-least-once, a handler may receive the same event more than once on retries. A seen-events store keyed on event.id distinguishes a retry from a new event:

Managing endpoints via the Dashboard

Go to Settings → Webhooks in your Tybrite dashboard to:
  • Create, edit, disable, or delete endpoints
  • Choose which event types to subscribe to (or select “All events”)
  • Send a test event with one click to verify your handler
  • View per-endpoint delivery statistics and the full event log
  • Retry failed deliveries

Managing endpoints via the API

See the WebhooksService SDK reference or the API Reference for the complete endpoint documentation.

Security checklist

  • Verify X-Tybrite-Signature on every delivery before processing
  • Reject requests where |now − timestamp| > 300s (replay protection)
  • Use timingSafeEqual for constant-time comparison (prevents timing attacks)
  • Store signing_secret in a secrets manager — never in source code
  • Return 2xx immediately and process events asynchronously
  • Implement idempotency using event.id
  • Use HTTPS with a valid TLS certificate on your endpoint