MailerLite Comfort API & Webhooks: Do You Need Power?

1. Buy the missing entitlement, not the API label

The current pricing FAQ gives starting prices of $12/month for Comfort and $25/month for Power. Both paid plan cards list full API access. Free has limited API access and cannot send through the API/MCP route. Power adds broader sending, team and active-feature capacity; its unlimited sending remains subject to fair use.

The $13 starting-price difference is not your universal upgrade quote. Compare the same subscriber tier, billing period, tax and currency in the actual checkout. A queueing failure does not establish that Power buys additional API throughput.

Some campaign-endpoint documentation still uses Growing Business/Advanced terminology. MailerLite's transition FAQ explicitly maps those names to Comfort/Power and says accounts move at renewal or a manual plan change. Verify the account's actual plan generation rather than treating an old label as a new restriction.

2. Keep three request budgets separate

The current API introduction documents 120 requests per minute and a 429 response when the limit is exceeded. Follow the returned retry guidance and smooth bursts instead of repeatedly retrying immediately. Tokens belong to their creating user and stop authenticating if that user is removed.

Batching supports up to 50 calls per request. Webhook operations are not supported inside API batches. A batch consisting only of subscriber upserts uses the import path, which has an additional five-import-creation-requests-per-minute limit. This is not a five-subscriber-per-minute limit. Inspect each batch response rather than assuming that an outer successful response proves every item succeeded.

Write down the busiest short interval, not just a daily average. A job that releases all its work at the top of the hour can overwhelm a budget that comfortably supports the same work spread out. Reserve space for retries and staff activity. If batching and pacing fix the problem, an upgrade has not demonstrated value.

3. Acknowledge webhooks before slow business work

MailerLite documents delivery only for active accounts, a successful 2xx response in less than three seconds, and three further attempts after delays of 10, 100 and 1,000 seconds. The current API uses a Signature header containing HMAC-SHA256 of the JSON payload with that webhook's secret. These are current-API rules, not instructions for MailerLite Classic.

Our proposed design is to verify the raw body, durably record the event, acknowledge it promptly, then process slower CRM work in a worker. Do not acknowledge before the event is safely retained. If persistence fails, alert and preserve a recovery route instead of silently discarding the message.

Make repeated processing harmless. A retried update must not create duplicate contacts or charges. Test single and batched payloads against current schemas; the event table requires batchable handling for campaign opens, campaign clicks and subscriber deletion. This is a proposed design, not a tested delivery guarantee.

4. Test the event that never arrives

A critical exception sits in the product help: subscriber.active does not fire after manual reactivation. The broader developer event description must be read together with that exception. A sync relying only on this notification can miss a staff member's manual change.

Use a harmless staging contact to document which actions emit events and which require reconciliation. Do not interpret either an active status or a received callback as fresh marketing permission. Keep consent evidence separately, and never turn a reconciliation job into automatic resubscription of previously opted-out contacts.

Likewise, plan token ownership before a staff departure. Inventory dependent jobs and test replacement credentials before removing the creating user. Protect secrets and avoid logging unnecessary subscriber data. These operational checks are not benefits that a pricing card can prove.

5. Compare operating rules across platforms

Mailchimp's webhook guide covers audience-event handling and signature verification. Brevo publishes endpoint-specific rate limits and a separate retry policy. ActiveCampaign documents five requests per second per account and Retry-After handling. These different units and delivery rules should be evaluated against the same workload; they are not a ranking of inbox placement or evidence of MailerLite parity.

Ask each vendor which requests count, what happens during an outage, how authenticity is checked and whether the needed capability is in the selected plan. A higher headline limit cannot compensate for a required event that the platform does not emit.

6. Decide after a small failure test

Before committing, run four proposed checks: required reads/writes succeed under the intended account; duplicates and a downstream outage do not lose or repeat work; a burst drains within the documented budgets; manual reactivation and token-owner removal have an explicit recovery procedure. Record expected and observed outcomes, leaving results blank until tested.

Stay on Comfort when these checks pass and the relevant marketing capacities fit. Consider Power when a verified seat, sending, automation or other plan allowance blocks the real workflow, then compare the account-specific price difference. Keep engineering costs separate from subscription costs. Do not promise a fixed return from a hypothetical saving.

The practical verdict is to pay for a documented missing capability, not for the assumption that a premium tier repairs integration reliability. Toolnavia may earn a commission through the MailerLite purchase button; it does not provide an exclusive discount, raise rate limits or guarantee delivery.