Skip to main content
Inbound webhooks are how the outside world tells Senderz something happened: a new order, a fulfilment, a review, a bounce, a delivery receipt. Most of them are set up for you when you connect an integration. A few platforms have no way for us to register a webhook on your behalf, so you paste a URL into their dashboard yourself. This page tells you which is which, and how to tell when something has stopped.

​
Where store events arrive

Every workspace has its own inbound address per platform:
You never have to build that URL by hand. Whenever you need it, Senderz shows it to you with the workspace ID already filled in, in the connect dialog for that platform. Six platforms deliver here: Shopify, WooCommerce, Konimbo, Stripe, Tranzila and iCount. Any other value in the platform slot is rejected.
The address contains your workspace ID, and for Konimbo, iCount and Tranzila it can also carry your signing token. Treat it like a credential. Paste it only into the store or payment dashboard it belongs to.

​
Who provisions what

This table reflects what is wired end to end today. Where a platform needs a manual step, Senderz shows you the exact steps and the URL to copy at connect time.
Wix cannot be connected today. A Wix receiver exists and will verify and process events, but there is no Wix connect flow in the app, so nothing can map a Wix site to your workspace. Wix events sent now are logged and discarded. Do not plan a Wix launch around this. See Wix.
Magento is polled, not pushed. Senderz checks for orders changed since the last run roughly every ten minutes, so Magento activity arrives on that cadence rather than within seconds. Nothing to configure. See Magento.

​
What gets registered

Twelve store topics are registered at install: orders/create, orders/paid, orders/cancelled, orders/fulfilled, orders/partially_fulfilled, refunds/create, fulfillments/create, fulfillments/update, checkouts/create, checkouts/update, customers/create, customers/update.Registration is attempted topic by topic, so a store missing one permission still gets the rest. If your install predates a topic being added, reconnecting the store registers the missing ones. Registration is matched on topic plus delivery address, so reconnecting never creates duplicates.Shopify also sends app-level notifications to a single address that we declare in our Partner dashboard: app uninstall, billing changes, and the three privacy topics Shopify requires. Those are not per store and are not something you configure.product_viewed on Shopify does not come from a webhook. It comes from the storefront pixel, which is activated at the same time. If orders are landing but product views are not, that is the pixel, not the webhooks.
Four topics are registered using the store keys from the connect flow: customer.created, customer.updated, order.created, order.updated.Order status is what decides the event. A pending, on-hold or failed order becomes a started checkout, which is what makes abandonment capture work with the Israeli external payment pages. Processing counts as the order, and completed counts as fulfilment.A WooCommerce store has two inbound paths, and they are separate on purpose. Store data arrives over these webhooks. The Senderz WordPress plugin sends its own order, cart and checkout activity using your workspace ID and API key, because the guided plugin connection never receives store API keys and therefore cannot create webhooks. The two paths de-duplicate against each other, so an order that arrives twice is counted once.See WooCommerce.
Five events are registered with your API token: order_created, order_after_payment, order_status_created, customer_created, item_inventory_updated.Every event uses the same callback URL. The event name and your private token ride in the query string, which is how we tell them apart and how we verify the call came from your store.If we cannot register them, the connect dialog says so and shows you the steps: open your Konimbo admin, go to Settings, then Advanced, then Webhooks, add a webhook, pick the event, and paste the URL exactly as shown. Repeat for each event you want. The dialog also tells you when only some of the five registered, so you know which are left.See Konimbo.
Senderz creates a webhook endpoint in your Stripe account for customer.created, checkout.session.completed, payment_intent.succeeded and charge.refunded, and stores the signing secret Stripe returns.The restricted key you paste needs Customers read and Webhook Endpoints write. Without the second one the endpoint is never created and no Stripe events reach you. Live and test keys both work.Reconnecting replaces the endpoint rather than adding a second one. Disconnecting removes it.
Both are manual, and both are set up from their connect dialog.For iCount, copy the webhook URL shown under Webhook URL to paste in iCount and add it in iCount under Settings, then Webhooks, for the invoice, receipt and credit note events you care about. Set the same Webhook signing secret in both places.For Tranzila, copy the URL shown under Webhook URL to paste in Tranzila and add it in Tranzila under Web Hooks as a notification destination for successful sales and refunds. The signing secret you set in Tranzila must match the one you entered in Senderz.Disconnecting either one does not remove the webhook from their side. Delete it there too, or they will keep sending to an address that no longer accepts anything.

​
Reviews and loyalty

Reviews and loyalty apps post to their own addresses:
When you connect one of these apps, Senderz generates a signing key and shows you the exact address to paste. For Loox, Yotpo Reviews, Rivo and Yotpo Loyalty the address already includes your key, so paste it exactly as shown and do not trim the query string. Some dashboards also have a separate signing key or validation key field; the dialog shows you that value separately for those.
The key is shown once. If you lose it, connect again to generate a new one, then update the address in the vendor dashboard. The old address stops working the moment you reconnect.
Judge.me is the exception. Give it your shop domain and private API token and Senderz registers the review webhooks for you. Two things to expect:
  • Reviews you bulk import into your reviews app do not create events in Senderz. Only new activity from the moment you connect reaches us.
  • The vendor may keep sending its own emails. Judge.me turns its review requests off automatically. Loox turns off requests and reminders but keeps sending thank you, photo and video reminder, and discount reminder emails. Yotpo turns nothing off. The connect dialog spells this out per vendor.

​
How every delivery is authenticated

Each platform proves it sent the request in a different way, because each platform offers something different. Senderz checks that proof before it looks at the body. An unsigned or wrongly signed delivery is rejected with 401 and nothing is stored. Every comparison is constant time, so a wrong secret leaks nothing about the right one.
Reconnecting an integration mints a new secret. If that platform is one you configured by hand, the old address stops verifying immediately, so update the vendor dashboard in the same sitting.

​
How an inbound event is handled

1

Verify

The signature or shared token is checked before anything else. A missing or wrong signature is rejected with 401 and nothing is stored.
2

Keep the raw copy

The original payload is written to storage as an audit copy, so an event can be replayed later without asking the platform to resend it.
3

Normalise

The platform’s payload is mapped to one shared event shape, so a Shopify order and a WooCommerce order reach the rest of the product identically.
4

Queue

The event is handed to a background worker and the platform gets its acknowledgement immediately. Shopify in particular gives a webhook only a few seconds before it counts as failed, so nothing heavy runs while it waits.
5

Process

The worker matches or creates the contact, writes the activity timeline entry, records the analytics fact, updates consent if the payload carries a real signal, enrols any matching automation, and fires your own outbound webhooks.
The canonical events are orders (order.completed, order.paid, order.refunded, order.fulfilled, order.partially_fulfilled, order.cancelled), shipping (shipment.confirmed, shipment.out_for_delivery, shipment.delivered), checkout (checkout.started, cart.abandoned) and contacts (contact.created, contact.updated).

​
Redeliveries are de-duplicated

Every inbound event carries a de-duplication key derived from the thing it describes, usually the order or customer ID, not from the platform’s own event ID. The key is remembered for eight days. That matters more than it sounds. Platforms send two different notifications for one order, and they resend when they think a delivery failed. Keying on the entity means both collapse onto one record, so revenue is counted once. Keying on the platform’s event ID would count it twice. A few consequences worth knowing:
  • Resending an old webhook from the platform’s dashboard within eight days does nothing. Nothing is duplicated, and nothing is corrected either.
  • A contact update is keyed to include the update timestamp, so genuine repeat edits to the same customer are each processed.
  • Order events from the WordPress plugin and from native WooCommerce webhooks share the same key, which is why running both does not double your revenue.

​
When events stop arriving

Start at Integrations, open the platform, and read the Recent data panel. It lists the events that platform is expected to produce with the most recent timestamp and today’s count for each. That panel is the fastest answer to “is anything landing at all”, and it tells you whether the gap is everything or one event type.
Check the connection first. A disconnected integration still accepts inbound deliveries and answers with a success code, then discards them. The platform’s own webhook log will look perfectly healthy while nothing reaches you.On the integration page, Connection details shows when it was connected and last updated, and Data sync shows the last sync time. If the connection is disabled or shows an error, reconnect.
Look at the webhook log in your store or vendor dashboard. The response code tells you which problem you have.A 401 means the signature did not match. For iCount, Tranzila and the reviews and loyalty apps, that almost always means the secret in the vendor dashboard is not the one Senderz holds. Reconnect in Senderz to mint a fresh secret and paste it again.A 400 means the platform name or the workspace ID in the address is malformed, or the body was not valid JSON. Re-copy the URL from the connect dialog rather than editing the one you already have. A truncated query string is the usual cause for Konimbo, Loox, Yotpo and Rivo.A 404 means the address itself is wrong, usually a typo or a trailing character picked up when it was pasted.A success code with nothing arriving in Senderz is a different problem. See the previous item.
This is expected, not a fault. A checkout event that carries neither an email address nor a phone number is discarded, because there is nobody to attach it to.Shoppers usually enter their email partway through checkout, so the first notification for a checkout is often anonymous and the later one carries the address. The later one is the one that lands and starts your abandonment automation.
A store that was installed before a topic was added, or that is missing a permission, keeps its other topics and silently lacks that one. Reconnect the store to register the missing topics and grant the current permissions.If product views specifically are missing while orders are fine, that is the storefront pixel rather than the webhooks. Reconnecting activates it again.
Press Sync now on the WooCommerce integration. It re-creates any of our webhooks the store is missing before it starts the sync, and skips the ones already pointing at us, so it is safe to run repeatedly.If the store data connection and the plugin are both listed as connected but nothing is arriving, check them separately. Complete your WooCommerce setup on the integration page shows which of the two is healthy.
That points at credentials expiring on the platform side rather than at the webhook. Check Data sync for the last successful sync and the connection card for an error.

​
Delivery feedback for email and SMS

Bounces, complaints, opens, clicks, delivery receipts and inbound STOP replies come in the same way. They drive suppression, the status shown on each message, and the engagement automations that react to an open, a click, a bounce or a failed SMS. You do not configure any of these; they are part of the sending setup.
SES feedback can arrive over two paths at once, the direct notification and the queue. That is deliberate redundancy, not a bug. Both carry the same de-duplication key, so a bounce is recorded once no matter which path delivers it first.
Elastic Email is the only receiver that answers a GET. It uses one to check that the notification URL is reachable before it will save it.

​
Sending Senderz your own events

To push events from your own backend, POS or any other system, use the event ingest API. Send POST /events/ingest with your workspace ID and API key. It matches or creates the contact and enrols automations that listen for that event name.
Event ingest is the developer-facing inbound path and is the right choice for anything the store platforms do not already send. It is not a way to replay store webhooks; those are handled for you.