Email for developersOne API call, on infrastructure you can ssh past, not rent forever.

The first transactional email in most apps is a password reset or a signup confirmation, called from a backend route with a fixed recipient and no user input in the to field. That single call is the whole integration surface for a while: an API key, a base URL, and a JSON body. What changes as the app grows is not the shape of that call, it is how many other things start depending on the same sending path, and whether an agent working on the codebase ends up with a send credential of its own.

A hosted API-first ESP gets that first call out fastest, because there is no AWS account to open first. The tradeoff shows up later, once volume is real and the per-email rate on a hosted plan is being compared against what the same volume costs on Amazon SES directly.

A transactional email API by itself does not need campaigns, automation or a shared inbox behind it, and a small app might never touch those. The decision point is narrower than the full platform question: does the account issuing the API key belong to the app's own AWS, or to a vendor whose pricing, rate limits and account-review policy sit outside the app's control.

• A hosted API ESP is fastest to the first send and includes its own dashboard, but bills per email at a markup over the underlying sending cost, and a policy review on the vendor's side can pause every app using that account.
• An owned install puts the API key, the sending domain and the account behind Amazon SES in the app's own AWS, at SES's per-message rate, with campaigns and an inbox available on the same stack later if the app needs them.

1. License and deploy. The platform costs $199 as a one-time purchase, and the one-click Create stack link installs it directly into the app's own AWS account.
2. Verify the sending domain. The app dashboard generates the DKIM, SPF and DMARC records; one click applies them on Route 53 in the same account, otherwise they are pasted into whatever DNS provider the domain already uses.
3. Create a scoped API key. Send-only integrations need only the email:send scope; a key created for the app's backend should not also carry audience or campaign write access.
4. Send inside the SES sandbox first. A new AWS account only delivers to verified addresses until production access clears, which is enough to run the integration against a test inbox or the SES mailbox simulator.
5. Request production access, using the link the app provides to AWS's own form, before real users depend on the reset or confirmation flow going out.

Every send is one POST to /v1/emails, authorized with an API key in the x-api-key header, to always an array even for one recipient. The body is either a raw subject plus html or text, or a stored template referenced by templateId or templateAlias with merge data, never both in the same call.

curl -X POST 'https://YOUR-INSTALL.cloudfront.net/v1/emails' \
  -H 'x-api-key: sbYOUR_KEY_HERE' \
  -H 'Content-Type: application/json' \
  -d '{
    "from": "no-reply@yourapp.com",
    "to": ["user@example.com"],
    "subject": "Reset your password",
    "html": "<p>Click the link below to reset your password.</p>"
  }'

A successful call returns 200 with a messageId from SES and an id for the send in your own ledger, which GET /v1/emails/{id} looks up later. A recipient on the account-wide suppression list, from an earlier bounce or complaint, returns 422 instead of silently dropping the message, so the calling code has something to log.

A coding agent that only needs to fire deploy notifications, receipts or alerts should get the same scoped key as any other backend service, not a broader grant borrowed from a human's session. An MCP grant limited to Send mail for one domain, or an API key scoped to email:send alone, lets the agent call send_email or POST /v1/emails without any path into the inbox, the contact list or campaign tools.

That distinction matters because send and read-plus-reply are different jobs with different risk. An agent that only sends with fixed recipients set by your code, not by model output, has nothing to leak even if the session is compromised. An agent that also reads inbound mail and can reply needs a person approving the send, which is a separate grant and a separate workflow from the transactional path above.

A hackathon project or a demo that will never touch production has no reason to open an AWS account for a handful of test emails. A hosted API ESP's free tier gets the first send out in minutes, and the pricing gap only matters once volume is steady enough for the per-email markup to add up to something real, roughly where SES's $0.10 per 1,000 emails starts pulling ahead of a per-email SaaS rate.

It is also the better call for a team that needs SMTP specifically, since the send path here is HTTPS API and MCP only, or a team that will not run an AWS account under any circumstances. For everyone past the prototype stage who is already comfortable in AWS, the request shape does not change: the account behind the key does.