What is a webhook, and would I ever use one?

What actually gets sent

systeme.io describes the webhook action as sending trigger related data as an HTTP request in JSON format.

A completed opt-in, for instance, carries the funnel step and the funnel it happened on, plus the contact's id, email address, form fields and IP address, and the time it happened.

Here is that opt-in parcel field by field, with the values from systeme.io's own published example.

The type field at the top is how a receiving script tells one parcel from another. systeme.io publishes the value for each trigger, among them contact.optin.completed, customer.sale.completed, contact.tag.added, contact.tag.removed, contact.page.visited and contact.email_link.clicked.

A sale carries considerably more: the payment processor, the buyer's billing fields, the price plan with its amount and currency, the order and order item, and the resources handed over, meaning the tags and course access the purchase granted.

Two places to set one up

The account service. Profile picture, then Settings, then Webhooks, then Create. It asks for a name, the URL the data goes to, a secret key, and which events to listen for. An Active toggle turns it on and off.

As an action. Send webhook is one of the actions available inside an automation rule and inside a workflow, so anything those can be triggered by can fire one.

A rule built the way article 144 describes, from one opt-in page, only watches that page, so testing it from a different page will not fire it. A rule or workflow triggered by something else, such as a tag or a sale, is not tied to a page at all.

The six events the account service supports

• Contact created
• Contact tag added
• Contact tag removed
• Opt-In
• New sale, covering funnels and creator stores
• Sale canceled, meaning a cancelled subscription or a refunded one-off payment

What has to exist at the other end

A server endpoint that can handle the request, and it has to be HTTPS. systeme.io is explicit that the secure address is required, so a plain HTTP URL is not enough.

Requests arrive from three fixed addresses: 185.236.142.1, 185.236.142.2 and 185.236.142.3. Those are what a firewall needs to let through.

Nothing has to be built to look at the data first. systeme.io's worked example points the rule at a free request-inspection service, naming RequestBin and Pipedream.

Paste the address that service hands you into the action field, do a test opt-in on your own page, then reload the service's page to read what turned up.

That is the cheap way to find out whether a webhook is worth the trouble, before any code exists to receive one.

When a delivery fails

Nothing is dropped straight away. Deliveries run in the background, and a server that is down, slow or returning an error gets retried up to 12 times, with the gap growing to around 24 hours between attempts. In practice systeme.io keeps trying for several days.

The three dots beside a webhook offer View logs, split into a Message log showing time, event type and detail, and a Delivery log showing whether the far end accepted it. A Copy log button lifts either one out for a developer.

Neither article explains how to view past delivery attempts for the automation rule or workflow version. That visibility only exists for the version built under Settings. Building it there instead, purely to get the log, is one way around a failure that otherwise cannot be inspected at all.

Would I ever use one?

Only when the tool you want to reach is not already connected. Google Sheets is available as a workflow action, and Zoom, Google Meet and Google Calendar sit in the integrations settings, so none of those need a webhook.

A webhook is one route to everything else, and the price of it is having somewhere to receive the request. Without that, there is nothing to point it at.

One thing to know before sharing

The Send webhook action is not included when a workflow is shared with another account. A workflow that arrives by link comes without it.