Sending API, SMTP & developer experience
How this is scored
How an application sends mail: a REST API and an SMTP relay with their limits stated, official SDKs and drivers for named languages and frameworks (PHP and Laravel, Node, Python, Ruby and Rails, Java, Go, .NET), stored templates with variables and versions, batch sending, attachments, idempotency keys, scheduled sending, a test or sandbox mode that does not deliver, inbound email parsed into a webhook, and the quality of the API reference and guides.
0 — Not a sending service; an application cannot send email through it by API or SMTP.
3 — An API or SMTP credentials to send a message; SDKs, templates, limits and a test mode are basic or not described.
5 — A documented REST API and SMTP relay, official SDKs for several named languages, stored templates with variables, attachments and batch sending, rate limits stated, a sandbox or test mode, and quick-start guides for named frameworks.
8 — An API reference with every endpoint and error code, idempotency keys, scheduled sending, template versions and a template language documented, inbound email parsed to a webhook, an OpenAPI specification or official CLI, framework drivers maintained by the vendor, and a migration guide from named competitors.
10 — An API a team builds its product on: versioning and deprecation policy published, backward compatibility stated, full parity between API and SMTP features, local or staging test tooling that mirrors production, and every limit, timeout and retry behaviour documented.
The Agency Lead
A documented REST API and SMTP relay with official SDKs for all seven named languages, batch sending up to 1,000 messages per request, attachments, templates with variables and API template creation, idempotency keys, scheduled sending, a sandbox mode, inbound parsing, stated rate limits, and domain verification and validation by API — which is exactly how I would onboard thirty client domains. 1 4 11 12 14