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
The sending path is real for both integration styles my teams use: a documented REST API with an example endpoint, plus Endpoints, Response Codes and Rate Limiting sections in the developer docs, an SMTP relay, official libraries and full code examples in JavaScript, Node, PHP, Ruby and Python. What I could not find on the captured pages is stored templates, attachments, batch sending, a sandbox mode or inbound parsing, so I cannot place it higher. 7 12 3 11