Skip to main content
The WebhooksService class (accessed via client.webhooks) manages outbound webhook endpoints and provides access to the event delivery log.
Secret key required. All webhook management endpoints require a secret key (tybrite_sk_*). Publishable keys return 403 Forbidden.

Overview

Webhooks allow your systems to receive real-time push notifications when events occur in your store — eliminating the need to poll the API. Every delivery is HMAC-signed so you can verify authenticity before acting on the payload. Supported event categories: Orders, Payments, Customers, Inventory, Cart, Gift Cards, Promotions, Catalog Sync. Delivery contract:
  • At-least-once — your endpoint must be idempotent. Use event.id for deduplication.
  • HMAC-signed — verify with the signing_secret returned at endpoint creation.
  • Best-effort ordering — use event.created_at for sequencing, not arrival order.
  • Automatic retries — failed deliveries are retried with exponential backoff.
  • Auto-disable — an endpoint that fails 20 deliveries in a row (each after its retries are exhausted) is automatically disabled. Re-enable it once it’s healthy; see Endpoint health & auto-disable.

Signature Verification

Every webhook delivery includes the header:
Verify it in your endpoint handler:
Always read the raw request body (before JSON parsing) for signature verification. Parsers may reformat the JSON, producing a different byte sequence and causing verification to fail.

Endpoint Management

createWebhookEndpoint 🔒

Register a new HTTPS endpoint to receive event notifications.
Response
The signing_secret is shown once at creation. It cannot be retrieved again. Store it in your secrets manager (e.g. AWS Secrets Manager, Doppler, Infisical) immediately.
To subscribe to all events, pass ["*"] as the events array:
Supported event types: The store-lifecycle, content, and feature-availability events describe a store growing rather than a transaction — the signal an automation tool uses to keep a storefront in step with the store (a promo banner the moment a promotion goes live, a reviews block when reviews are first approved, a feature surface the moment its data exists). See the webhooks guide for the full catalogue and the automated workflows guide for the pattern.

listWebhookEndpoints 🔒

Response
The signing_secret is not included on list or get — it’s returned only once, at creation.

getWebhookEndpoint 🔒

Returns full endpoint details including delivery statistics.

Endpoint health & auto-disable

Every endpoint tracks its recent delivery health: When consecutive_failures reaches 20, the endpoint is automatically disabled (enabled: false) so a permanently-dead endpoint stops accumulating deliveries. Fix the endpoint, then re-enable it — re-enabling resets the failure counter and clears disabled_reason:

updateWebhookEndpoint 🔒

All fields are optional. Only provided fields are updated.
The updated endpoint is returned (without signing_secret):
Response

deleteWebhookEndpoint 🔒

Soft-deletes the endpoint. In-flight deliveries are not cancelled.

sendTestWebhookEvent 🔒

Sends a synthetic test payload to an endpoint. Use this to verify your signature verification code and endpoint connectivity before going live. The payload carries "test": true (it’s synthetic — data.object holds placeholder values, so your handler should skip side effects) and a livemode flag reflecting the key’s environment. These are two distinct signals — see livemode vs test.
Response
Available test event types: order.created, order.paid, order.fulfilled, order.shipped, order.cancelled, payment.succeeded, payment.failed, customer.created, product.created, product.stock_low, cart.abandoned, gift_card.issued, promotion.applied, promotion.activated, collection.created, post.published, review.approved, store.updated, payment_provider.connected, feature.status_changed, feed.sync.completed, channel.sync.completed.

Event Log

listWebhookEvents 🔒

Returns the event log in reverse-chronological order. Useful for debugging delivery failures or auditing event history.
Each call returns the same shape — a webhook_events array plus a pagination cursor:
Response
Each event also carries an environment field (production or sandbox) so you can tell live and test events apart in the log.

getWebhookEvent 🔒

Returns a single event with all its delivery attempts across all endpoints.
Response

retryWebhookEvent 🔒

Manually re-delivers the event to all enabled endpoints subscribed to its event type. Each re-delivery is recorded as a new attempt.
Response

Event Payload Shape

All events use a consistent envelope:

livemode vs test — two different flags

The envelope carries two boolean signals that are easy to confuse but answer different questions. Check the one that matches what you’re deciding:
  • Use livemode to route — e.g. drop anything where livemode === false in your production handler.
  • Use test to skip side effects — don’t fulfil, charge, or persist when test === true, because the data is fake.
They’re orthogonal. A real order placed with a test key is livemode: false with no test flag — a genuine sandbox event you can process as an end-to-end integration test. A synthetic test fired while on a live key is livemode: true with test: true.
Use event.id for idempotency — store it and skip processing if you’ve seen it before:

Response Codes