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 endpointEvent catalogue
All events follow the same envelope shape — onlytype 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’sid 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:${timestamp}.${raw_request_body}. The secret is the signing_secret returned when the endpoint was created (per-endpoint, not the store HMAC secret).
Serverless function 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 onevent.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-Signatureon every delivery before processing - Reject requests where
|now − timestamp| > 300s(replay protection) - Use
timingSafeEqualfor constant-time comparison (prevents timing attacks) - Store
signing_secretin a secrets manager — never in source code - Return
2xximmediately and process events asynchronously - Implement idempotency using
event.id - Use HTTPS with a valid TLS certificate on your endpoint

