Connect email from your app’s backend, with the API key in its secret store and a real event checked before sending. An AI coding assistant can write a starter, but it must use your application’s actual authentication, database and hosting model. Pasting a key into a chat or frontend configuration does not make a working secure integration.
Separate the browser from the sending backend
The browser can ask your authenticated application to perform a customer action. Your server decides whether that action is allowed, records it and requests the appropriate email. Keep the sending API call behind that decision instead of exposing a generic “send to any address” endpoint.
Example: a password-reset form submits to your application. The server creates an eligible reset event according to your account-recovery rules, then uses the supported password.reset template. An email field supplied by the browser is not sufficient evidence on its own.
| Part of the app | Responsibility |
|---|---|
| Browser | Collect the customer action without holding sending credentials. |
| Application server | Authenticate and validate requests, look up events and call the email API. |
| Secret store | Hold the scoped API key and callback signing secret. |
| Event database | Store the real recipient, action and identifiers used for verification. |
Give your coding assistant a bounded implementation brief
A useful prompt is: “Inspect this app’s backend and authentication. Plan an Emailer API integration for password resets using the current API documentation. Keep EMAIL_API_KEY and CALLBACK_SECRET as server-only placeholders. Connect event verification to the real database. Identify the code and deployment steps I must review before a send.”
This is a planning prompt, not executable integration code. Replace the email type with your actual use case and require the assistant to identify missing infrastructure. Do not supply production keys, real reset links or customer records in the conversation.
Connect the right proof of an event
Account, security and appointment events use a signed HTTPS application callback on the exact verified sending domain. Verify the request signature before trusting the data, then query your database for the matching active event, recipient and message context. Follow the documented response-signing protocol too.
Do not deploy a callback that blindly returns approval. For payment receipts and paid orders, use the supported Stripe verification flow instead of substituting an application assertion. The integration must select the correct approved fixed template and version.
Validate without sending first
Emailer API validation checks the exact approved payload without sending or reserving send quota. Omit Idempotency-Key from validation. Inspect the named checks; a setup wizard marked complete does not override event freshness, suppression, capacity or other admission checks.
Then review the intended recipient and rendered content before an actual test send. Persist the source event ID, returned authorization ID and stable send idempotency key. A 202 response means the request is queued; use delivery logs and signed webhooks for later outcomes.
Review what will run in production
Check the generated code where it crosses a trust boundary: browser input, database lookup, signature verification, secret loading and retries. Make sure the deployment actually exposes the verification callback on the required domain and keeps secrets out of client assets and logs.
The included onboarding assistant can use saved account progress to generate a relevant starter. Treat the starter as the beginning of the app-specific integration, and test it in your own environment before routing live customer events.
- Use a sending-only key restricted to the intended domain where possible.
- Confirm unknown, stale and mismatched events are rejected.
- Verify a later delivery outcome instead of equating queue acceptance with an inbox result.
Common questions
Can a frontend-only app send directly?
Do not put a sending key in the frontend. Add an appropriate backend integration before using this workflow.
Is generated code already tested against my database?
No. The guide and generated starter do not establish application-specific test evidence. Your event lookup and deployed workflow need their own checks.
Continue with a related guide
Sources and next steps
Start free with setup help included · Read current plan limits
Reviewed by the Emailer API editorial assistant against the linked documentation. This guide explains the documented workflow; it is not a report of a new integration test.