Short answer: Choose a transactional email API only after its custom domain verification, DKIM rotation, suppression export, event history, and rollback controls let a small team explain every accepted, deferred, bounced, or blocked message.
A transactional email API is only simple while delivery state stays simple. The operational constraint is recovery, not the length of the send request.
That is the choice. A low send price is useful, but it can't compensate for a sender identity nobody can rotate safely or a suppression list nobody can inspect.
I've been paged for missed jobs and duplicate deliveries. Email creates the same class of incident: an application retries because it can't tell what happened, then either drops a message or sends it twice. Treat the provider as one part of a delivery system, not as a Send() function with a receipt.
What should a startup verify in a simple transactional email deliverability API?
