Why webhook coverage decides how fast a workflow can be
A webhook is the email platform calling your automation the moment something happens. Without one, Make or Pabbly has to ask the platform on a schedule, which is slower and, in Make, costs an operation for every check. [12]
All four platforms push some events, but they differ on which events, which plan unlocks them, what happens when your endpoint is down, and whether you can prove a request really came from them. The tables below come from each vendor's developer documentation; Moosend's route runs through its automation builder rather than a webhook settings page.
Event coverage at a glance
The five events most small senders want to act on are new subscriber, unsubscribe, bounce, link click and purchase. Here is what each platform documents.
| Event | MailerLite | Kit | beehiiv | Moosend |
|---|---|---|---|---|
| New subscriber | subscriber.created [1] | subscriber.created, subscriber.activated, subscriber.subscribed_to_form [3] | Subscription created and confirmed events [7] | Watch new Subscribers for a mailing list, or an automation posting to Make's Watch Events webhook [8] |
| Unsubscribe | subscriber.unsubscribed [1] | subscriber.unsubscribed [3] | Subscription deleted; newsletter list unsubscribed [7] | Depends on the automation trigger you build |
| Bounce | subscriber.bounced [1] | subscriber.bounced [3] | Not in the documented event list [7] | Depends on the automation trigger you build |
| Link click | campaign.click, batched only [1] | subscriber.link_clicked is planned, not yet subscribable [3] | Not in the documented event list [7] | Depends on the automation trigger you build |
| Purchase | Not in the webhook event list [1] | subscriber.product_purchased is planned, not yet subscribable [3] | Subscription upgraded and downgraded, plus tier events [7] | Depends on the automation trigger you build |
Delivery rules: plan, retries and signatures
Retries matter when Make is paused, a scenario errors, or your endpoint is slow. Signatures matter if you receive webhooks on your own server and need to reject forged requests.
| Vendor | Plan required | Retries | Timeout and batching | Signature |
|---|---|---|---|---|
| MailerLite | None stated in the webhook docs [1] | Three more attempts after 10, 100 and 1,000 seconds [1] | Respond within 3 seconds; click and open events must be batched [1] | Signature header, HMAC-SHA256 of the payload with the webhook secret [1] |
| Kit | None stated in the webhook docs [2] | Up to 8 attempts over about 41 hours: 30s, 2m, 15m, 1h, 4h, 12h, then 24h [4] | Each delivery holds 1 to 100 events of one type; history kept 30 days [2] | X-Kit-Signature, HMAC-SHA256 of timestamp and raw body; 5 minutes is a suggested tolerance [5] |
| beehiiv | Paid plans, Lite and above [6] | Not stated on the webhooks overview [6] | Not stated on the webhooks overview [6] | svix-id, svix-timestamp and svix-signature headers; secret under Settings, Webhooks [6] |
| Moosend | Not stated in Make's app docs [8] | Not stated [8] | Sent when the Moosend automation runs [8] | Not stated [8] |
Vendor notes
MailerLite has 14 events: subscriber created, updated, unsubscribed, added to group, removed from group, bounced, automation triggered, automation completed, spam reported, deleted and active, plus campaign sent, click and open. [1] Campaign click and open, and subscriber deleted, must be set as batchable. [1] A delivery counts as successful only on a 2XX response, and MailerLite warns that answering with 4XX or 5XX for business reasons leads to repeated events. [1] Webhooks are only delivered for active accounts. [1]
Kit's current webhook endpoints can subscribe to many event types, while legacy webhooks handle one event each and drop failed deliveries. [2] Endpoints are created in the app at app.kit.com/webhooks or through the V4 API. [2] Beyond subscriber events, Kit sends tag, custom field, sequence and broadcast events, plus a post published event. [3] Subscribing to a planned event such as link clicks returns a 422 error. [3] Returning 410 Gone stops retries immediately. [4]
beehiiv webhooks are set up under Settings, Webhooks, or with a POST to its webhooks endpoint, and only paid users on Lite and above have them. [6] Its documented events cover subscriptions (created, confirmed, deleted, upgraded, downgraded, paused, resumed), posts (sent, updated, scheduled), newsletter list subscriptions, podcast episodes and survey submissions. [7] Make's beehiiv app has instant modules for subscribers, confirmations, updates, unsubscribers, downgrades, survey submissions and post sends, set up by pasting Make's webhook URL into beehiiv's Settings, Webhooks. [9] Make's MailerLite app, by contrast, lists two watch modules, Watch Campaigns and Watch Subscribers, so check each module's description before assuming it is instant. [11]
Moosend's route is different. Make's Moosend app has a Watch Events trigger that fires when your Moosend automation transmits data to the webhook URL, and a Watch new Subscribers trigger for a chosen mailing list. [8] So the "event" is whatever automation trigger you build inside Moosend, which also means any change to that automation changes what Make receives.
Which workflows can be instant and which must poll
Instant works today for new subscribers on all four (beehiiv on paid plans only), for unsubscribes on MailerLite, Kit and beehiiv, and for bounces on MailerLite and Kit. Paid-tier changes on beehiiv can be instant through upgrade and downgrade events. [1][3][7]
Click-based workflows need MailerLite's batched campaign.click event; on Kit, link clicks are planned but not yet subscribable. [1][3] Purchases are best taken from the payment tool itself rather than the email platform: MailerLite's webhook list has no purchase event and Kit's is still planned. [1][3]
On Make, the receiving side has its own limits. Make processes up to 300 incoming webhook requests per 10 seconds, queues calls it cannot process at once, and by default answers 200 Accepted when a request enters the queue. [10] That quick reply helps with MailerLite's 3-second timeout. [1] Instant-webhook scenarios run in parallel unless you turn on Process data in order. [10] Make keeps webhook logs for 3 days (30 on Enterprise) [10], so check them soon after a suspected missed event.
| Workflow | MailerLite | Kit | beehiiv | Moosend |
|---|---|---|---|---|
| Welcome a new subscriber in another tool | Instant [1] | Instant [3] | Instant on Lite and above [6] | Instant via an automation [8] |
| Remove an unsubscriber from a CRM list | Instant [1] | Instant [3] | Instant [7] | Build in the automation |
| Flag a hard bounce | Instant [1] | Instant [3] | Poll or check in the app | Build in the automation |
| Tag a lead who clicked a link | Instant, batched [1] | Poll until the planned event ships [3] | Poll | Build in the automation |
| Start onboarding after a purchase | Use the payment tool's webhook | Use the payment tool's webhook [3] | Paid-tier upgrade events [7] | Use the payment tool's webhook |
Setup checklist
- Confirm plan access first: beehiiv webhooks need Lite or above. [6]
- Create the receiving webhook in Make, then paste its URL into the vendor's webhook settings. [9][10]
- For MailerLite click or open events, set the webhook as batchable and handle an events array. [1]
- If you receive on your own server, verify the signature header and reject Kit requests older than about 5 minutes. [1][5][6]
- Never return an error code for business logic; MailerLite treats it as a failed delivery and retries. [1]
- Turn on Process data in order in Make if events for the same subscriber must be handled in sequence. [10]
- Expect retries: Kit can redeliver for about 41 hours, so make the receiving scenario safe to run twice. [4]
Questions before you decide
Does beehiiv send webhooks on the free plan?
No. beehiiv's webhook documentation says webhooks are only available for paid users on the Lite plan and above. They are configured under Settings, Webhooks.
Can Kit send a webhook when a subscriber clicks a link or buys a product?
Not yet. Kit lists subscriber.link_clicked and subscriber.product_purchased as planned event types, and subscribing to a planned event returns a 422 error.
What happens if my Make scenario is down when MailerLite sends a webhook?
MailerLite retries a failed delivery three more times, after 10, 100 and 1,000 seconds. Make also queues webhook calls it cannot process immediately and answers 200 Accepted when a request enters the queue.
How do I know a webhook really came from the email platform?
Check the signature. MailerLite sends a Signature header with an HMAC-SHA256 of the payload, Kit sends X-Kit-Signature, and beehiiv sends svix-id, svix-timestamp and svix-signature headers.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- MailerLite API: Webhooks Accessed 30 Oct 2026
- Kit developer docs: Webhooks overview Accessed 30 Oct 2026
- Kit developer docs: Webhook event types Accessed 30 Oct 2026
- Kit developer docs: Webhook retries Accessed 30 Oct 2026
- Kit developer docs: Verifying webhook signatures Accessed 30 Oct 2026
- beehiiv developer docs: Webhooks Accessed 30 Oct 2026
- beehiiv developer documentation index (webhook event pages) Accessed 30 Oct 2026
- Make Apps: Moosend Accessed 30 Oct 2026
- Make Apps: beehiiv Accessed 30 Oct 2026
- Make Help: Webhooks Accessed 30 Oct 2026
- Make Apps: MailerLite Accessed 30 Oct 2026
- Make Help: Operations Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.