Start with a single customer action, such as requesting a password reset. Connect the sending domain, approved template and event verification for that action before extending the integration to other email types.
1. Create an account and choose an event.
Use Google sign-in or an email login link, then choose the email you want to send. The onboarding wizard stores progress in your account. Returning users can select another sender while reusing checks that remain verified.
Password resets, account verification, sign-in alerts and appointment confirmations use an application callback. Payment receipts and paid-order confirmations require Stripe verification. Choose the matching event path at the start; a generic transaction label cannot authorize a receipt.
2. Verify your sending domain.
Add the domain and follow the exact records returned for that account. Ownership and SPF checks precede DKIM provisioning; after the signing record becomes available, publish the returned DKIM and DMARC values and check again. Existing SPF and DMARC policies must be reconciled, not blindly replaced.
The assistant can inspect DNS and prepare supported TXT additions after an authorized Cloudflare connection. Review the changes before applying them. Use the DNS setup guide when records conflict or verification remains pending.
3. Install an approved template.
Pick a catalog template for the selected domain and event type. Only the approved published version qualifies for sending. Editing a draft or publishing a custom version does not approve it. The approved templates constrain variables such as codes, dates, identifiers and HTTPS links on the verified domain.
4. Connect the real application event.
For nonfinancial events, register an HTTPS callback on the exact verified sending domain. Keep its shared secret on the application server. Verify the HMAC signature of each proof request before trusting the data, then query your database for the matching active event, recipient and message context.
The event must have occurred within the previous 15 minutes; a one-minute future clock skew is tolerated. Requests time out after 10 seconds. A callback that approves every request defeats the event check. Follow the exact response-signing protocol in the application callback reference.
For payments and paid orders, connect the supported Stripe verification flow instead. A website assertion alone does not replace payment-provider verification.
5. Generate and integrate server-side code.
The built-in assistant can generate Node.js, Next.js, Express or Python starters using your setup state. You still need to connect the code to your actual database, configure secrets and deploy it in your application. Never expose the API key or callback secret in a client bundle.
# Choose the SDK for your server
npm install https://emailerapi.com/sdk/amgmail-sdk-0.13.1.tgz
# or
python -m pip install https://emailerapi.com/sdk/amgmail-0.4.1-py3-none-any.whlThe existing SDK package names use the AMGMail name. The consumer service is Emailer API. Use the current OpenAPI contract and verification and send example for the exact payload, rather than sending arbitrary HTML.
6. Validate, review, then send.
Validation checks the request without sending or consuming quota. Before an actual send, review the recipient and rendered message and confirm that current account and shared capacity permit it. Sending creates a quota reservation; a later failure or cancellation does not undo that reservation.
A 202 response means queued. Relay acceptance and eventual destination outcomes are different events. Use signed webhooks and delivery logs to follow the message; missing placement measurements remain unavailable.
Your launch acceptance checklist
- Account access, owner verification, domain and signing are ready.
- The correct approved template version and genuine event verifier are connected.
- Keys are scoped to the sending domain and stored on your server.
- Your callback rejects unknown, stale or mismatched events.
- The exact request validates, and your peak demand fits current capacity.
- An actual test send has been explicitly reviewed and its later result inspected.
Finishing the wizard sends no email. It records setup evidence; it does not establish first-delivery evidence or override checks immediately before sending.