Transactional email: durable receipts, honest about duplicates

An app that sends email has two ways to fail its users: a message that should have gone and didn't, and the same message twice. A plain "insert, then call the provider" does both, depending on where it crashes. This skill is the shape that loses nothing and sends a duplicate only in a narrow, named case, plus the unsubscribe, environment and domain rules that go with it.

It was learned on a monitoring product that sends alert email (an incident opened, an incident resolved, a test) through Postmark, over its HTTP API with plain fetch, from a scheduled sender, named here only by kind. The mechanics carry to Resend, SES or any provider with an HTTP send API; where providers differ, both are said, with the date they were read. The identity provider's own email (sign-in codes, invitations) is not covered here: it sends that itself.

Terms used here. An event is the thing that happened (an incident opened, an invoice paid). A message is one email about it to one recipient. A receipt is the durable row that says what became of that message. The sender is the code that turns pending receipts into provider calls, wherever it runs.

What binds