Connect it to wherever your sales actually happen

Keeping an integration healthy

Integrations fail quietly more often than loudly. A plugin gets deactivated during a site update, a webhook URL is left pointing at a staging site, an order status is renamed and the trigger stops matching. In each case nothing errors visibly, requests simply stop going out, and the first sign is a report that looks unusually quiet.

Each integration in your account keeps a running event count and the timestamp of the last event it received. That pair answers the only question that matters when feedback volume drops: is the store still calling us? If the last event was three weeks ago, the problem is upstream and you can go straight to the plugin or webhook settings rather than debugging the feedback platform.

Integrations can also be paused rather than deleted, which is the right move during a site migration or a seasonal shutdown. The configuration and its history stay intact and can be switched back on without regenerating URLs or reconfiguring anything at the other end.

One more habit worth adopting: after any significant change to your store, place a small test order using an address you control and confirm the request arrives. It takes two minutes and it is considerably cheaper than discovering a month later that nothing has been sent since the theme update.

Choosing which channel an integration sends on

Each integration is configured to send on one channel, and the right choice depends less on preference than on which contact detail your orders reliably contain.

Online stores almost always capture an email address and frequently make the phone number optional, which makes email the sensible default. Point of sale and booking systems often have the reverse problem: a mobile number is captured because it is needed to confirm the appointment, while the email field is left blank half the time. In that case SMS or WhatsApp will reach far more customers than email would.

If a payload arrives without any usable contact detail, no request is sent, but the event is still counted. That is deliberate, because the counter then tells you something useful: a store where events are arriving but requests are not going out has a data capture problem at checkout rather than an integration problem.

Running two integrations against the same store, one on each channel, is possible but rarely worth it. It doubles the chance of asking the same person twice, and the deduplication guard works on contact details rather than across channels. Pick the channel your orders actually carry.

What happens between the webhook and the message

An incoming order does not go straight out as a message. Several checks sit in between, and knowing what they are makes it much easier to understand why a particular customer was or was not contacted.

First, the secret in the URL is matched to an active integration. If the integration has been paused or deleted, the call is rejected. Second, the form the integration points at must be published; a draft form causes the request to be refused rather than sending customers to a page that cannot accept answers. Third, the payload is parsed for an email address, phone number, name and order reference. Fourth, the contact is checked against your suppression list. Fifth, deduplication looks for a recent request to the same person.

Only after all five does a message get created, and from that point it enters the normal dispatch pipeline with its own delivery status. The effect is that an integration cannot accidentally message someone who has opted out, cannot message the same customer twice for one purchase, and cannot send anyone to an unpublished form.