Skip to main content
Inbound webhooks are how the outside world tells Senderz something happened — a new order, a bounce, a delivery receipt. You don’t usually configure these directly; store connectors provision them for you. This page explains the model.

​
Store events

Store platforms POST events to a per-workspace inbound URL. Senderz verifies the signature (when a secret is on file), persists the raw payload for replay, normalises it to a canonical event, and runs it through the pipeline:
1

Verify

Signature check per provider (Shopify/Woo HMAC; Wix RS256 JWT). Magento is poll-based, not webhook-based.
2

Persist raw

The raw payload is written to object storage as the audit copy.
3

Normalise

Mapped to a canonical StoreEvent (order, checkout, shipment, contact).
4

Process

Resolve/create the contact → activity timeline → analytics facts → flow enrolment → outbound webhook dispatch.
The whole pipeline is idempotent — keyed on a deterministic dedupe ID derived from the entity (e.g. the order ID), not the provider’s event ID. Two provider events describing one order collapse, so revenue is never double-counted.

​
Provider feedback (email & SMS)

Deliverability feedback flows in the same way:
  • SES / ZeptoMail / Elastic Email → bounce, complaint, delivery, open, click events, verified by provider signature or shared secret.
  • SMS DLR (019 / CommPeak) → delivery receipts and STOP messages, verified by HMAC.
These drive suppression, message status and engagement-based flow triggers.

​
Custom events (yours)

To send Senderz your own events (from a backend, a POS, anything), use the event ingest API — POST /events/ingest with your workspace ID + API key. This resolves or creates the contact and enrols custom_event flows scoped by event name.
Custom event ingest is the developer-facing inbound path. Store webhooks are provisioned automatically by the connectors — you don’t wire them by hand.