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 Integrations → Webhooks in GC Admin, 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

In-store sales

The order events above describe the online store. A sale rung up at the counter is a separate record with its own events, so anything that must see all of a merchant’s revenue — accounting, fiscal reporting, loyalty — subscribes to both families.

Payments

Customers

Inventory & catalog

Cart & checkout

Agent checkouts

A checkout an AI shopping assistant prepared through the Agent API, or one a shopper’s standing instruction prepared. An order placed from a confirmed intent carries source_channel: "agent" on order.created, with agent_client_ref naming the API key or connected application that created the intent; an order placed directly through POST /v1/orders carries source_channel: "storefront".

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.

Your connection

Only reaches applications connected through Login with GC, and describes the connection itself rather than the merchant’s store.

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. Credit and approvals emit alongside them. b2b.credit.threshold_reached and b2b.credit.exhausted fire when a buyer crosses a share of their credit limit, and b2b.buyer.on_hold / b2b.buyer.released when they are stopped or let go again. Each fires on the crossing rather than the level, so a buyer who stays above a threshold produces one event rather than one per order. b2b.approval.requested / .approved / .rejected follow an order the buying organisation routes for internal sign-off before it reaches the supplier. b2b.replenishment.needed fires when stock falls to its reorder point. It is the one wholesale event that fires in the buying store about its own stock rather than in the supplier’s, and it carries the supplier that line was last bought from, so an automation can raise the reorder rather than only report the need.

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 Integrations → Webhooks in GC Admin 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