Your password resets should not share a quota with your newsletter

Most messaging platforms sell you a monthly send allowance. You pick a plan, you get a number, and everything you send counts against it. It is a clean pricing model and it hides a nasty failure mode.

Because "everything" includes the password reset someone needs right now to get into their account.

The failure mode

Picture a plan with 100,000 emails a month. Marketing runs a bigger campaign than usual — a sale, a product launch, a Black Friday push — and burns through the allowance on the 22nd.

What happens on the 23rd depends entirely on a design decision your provider made, probably without telling you:

• Hard stop. Sends start failing. Not just campaigns — everything. Password resets, order confirmations, two-factor codes, invoices, opt-in confirmations. Your marketing team's ambition just became a login outage, and the first you hear about it is a support ticket from someone who cannot get in.
• Overage. Sends continue and you are billed per message above the allowance. You get a bigger invoice, which is annoying and entirely survivable.

Both are defensible for marketing. Only one is defensible for a password reset. A campaign that stops sending is a missed opportunity; a password reset that stops sending is an incident.

Why the two are genuinely different

It is not just about importance. Marketing and transactional messages differ in ways that matter operationally:

Volume is predictable in opposite directions. Marketing volume is a decision — you choose to send 80,000 emails. Transactional volume is a consequence — it is whatever your users happen to do. You cannot plan your way out of a spike in password resets, and you should not have to.

Consent works differently. Marketing needs opt-in, and honouring an unsubscribe is non-negotiable. Transactional mail is sent because of an action the user took, and suppressing a receipt because someone unsubscribed from a newsletter would be its own kind of broken.

Frequency caps should not apply. A sensible marketing programme caps how often it contacts someone. Applying that cap to a transactional message means the third password reset in an hour silently vanishes — exactly when someone is struggling to get in.

Any platform that treats these as one category will get at least one of the three wrong.

What to check with your current provider

Three questions, and the answers are usually not on the pricing page:

1. At the limit, do you stop or bill overage? If it stops, you have an outage scheduled for whenever marketing has a good month.
2. Can I mark a message as transactional? Not "do you have a transactional product" — a separate product means a separate integration, separate templates and separate reputation. Can the same send call flag a message as transactional?
3. What still applies when I do? The honest answer is not "nothing". Suppression lists, budget caps and payment state should absolutely still apply. Only the marketing volume cap should lift.

If the answer to (2) is no, your only defence is to keep enough headroom that you never hit the limit — which means paying for volume you do not send.

How WeZend handles it

A send can be marked transactional: true, and that message is exempt from the monthly marketing cap. Over the cap it is billed per message as overage instead of being blocked:

curl https://api.wezend.com/v1/messages/send \
  -H "X-API-Key: $WEZEND_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "user@example.com",
    "channel": "email",
    "subject": "Reset your password",
    "message": "Use this link within 30 minutes: …",
    "transactional": true
  }'

Transactional sends are still counted, so usage stays visible and the bill stays honest — the flag lifts the cap, not the meter. It also exempts the message from marketing frequency caps and quiet hours, for the reason above.

What it deliberately does not do: it does not override suppression lists, budget caps, the prepaid balance check, or a region that is blocked. Those are not quota decisions. And on the Free plan with no card on file it still stops, because there is no way to bill an overage — we would rather say that plainly than invent an unmetered send path.

There is an obvious question here: if the caller sets the flag, what stops someone marking bulk marketing as transactional to dodge their own cap? Nothing much — but they pay per-message overage either way, so there is no free lunch, and the flag is stored per message so transactional and marketing volume can be reported separately. We chose that over guessing from content, because a wrong guess would silently block a real password reset, which is the exact failure this exists to remove.

Details in Sending messages and Billing, balance & pay-as-you-go.

The rule worth adopting

Running out of marketing budget should produce an invoice or a pause you chose. Running out of anything should never take down the messages your users need to operate your product. If your provider cannot separate those two cases, that is worth knowing before the month you find out the hard way.