# Emailer API — free transactional-only email API API base: https://emailerapi.com/v1 OpenAPI 1.24.0: https://emailerapi.com/openapi.json Guide: https://emailerapi.com/docs Signup: https://emailerapi.com/signup Setup: https://emailerapi.com/setup Analytics: https://emailerapi.com/analytics ## Scope and capacity $0 subscription, no automatic paid overages. New accounts receive 100 recipient reservations per UTC calendar day and 3,000 per calendar month. Existing saved account limits are preserved. Actual account allowances appear in GET /v1/usage. The initial shared sending pool supports 1,000 attempts/day, with its last 50 daily slots reserved for platform verification emails; this shared limit applies across customers. New domain limits start at 100/day and hour, with three seconds between attempts. Quota measures reservations, not deliveries. Queued messages must fit the available capacity and their authorization expiry. Capacity rejection consumes no quota. Limits rise only after reviewing measured delivery results. Only transactional mail for verified live customer events is accepted. Marketing, newsletters, broadcasts, multi-recipient messages, attachments, arbitrary sender/body overrides and customer-published unreviewed templates cannot send in production. Contact/segment/template APIs preserve existing data but do not authorize marketing. Each email needs one To recipient, a reviewed immutable template version, verified owner email and domain signing, a verified event bound to the exact tenant, recipient and rendered content, and current capacity. Admission and pre-SMTP checks enforce event freshness, revocation, suppression, signing, account holds and node health. No system can guarantee perfect abuse classification. Original Reach outgoing servers remain separate; the Emailer API node also hosts Reach incoming replies. ## Fast integration 1. Sign up, verify your domain's ownership/SPF/DKIM/DMARC, and confirm your account email. Install a catalog template in /setup. 2. Connect Stripe for receipts/paid orders, or a domain-bound HTTPS event callback for account/security/appointment events. Create a domain-scoped sending API key and keep it on your server. 3. POST /v1/transactional/events with event_id, event, email and exactly one of provider_connection_id or integration_id. This verifies an event without sending or reserving send quota. 4. Put the returned id and event in email.metadata.transaction_id and email.metadata.event. POST /v1/emails/validate without Idempotency-Key. Check can_enqueue. Validation never sends, spends quota or consumes the event. 5. POST /v1/emails with that exact payload and a stable Idempotency-Key. Preserve the source event, authorization and result. Retry the same payload/key after uncertain acceptance; never replace the key to force a resend. 6. Inspect email logs and signed webhooks. HTTP 202 means queued; SMTP relay acceptance, destination-MX delivery, recipient observations and inbox placement are different facts. Inbox/spam-folder placement is not measured. Fixed catalog: account.verification (CODE), password.reset (URL), security.alert (TIME, URL), order.confirmed (ORDER, URL), payment.receipt (PAYMENT, URL), appointment.confirmed (TIME, URL). Variables accept restricted codes, identifiers, dates and HTTPS URLs on the exact verified domain. Custom templates require review; publishing is not approval. ## Developer control plane Transactional integrations are fully discoverable and operable through the API: - `GET /v1/transactional/catalog` is public and returns every supported event kind, subject, HTML placeholders, variable types, and whether the event requires independent provider evidence. - `GET /v1/transactional/providers` and `GET /v1/transactional/integrations` list the account's configured connections without returning secrets. Use the existing DELETE endpoints to revoke a connection. - `GET /v1/transactional/events?limit=50` lists recent event authorizations. `GET /v1/transactional/events/{id}` returns its complete lifecycle (`active`, `expired`, `consumed`, or `revoked`). `DELETE /v1/transactional/events/{id}` revokes an active authorization and is safe to repeat. Expired/consumed events remain unchanged with revoked:false; this does not cancel queued emails. - Event listings honor domain-scoped sending keys. All event authorizations still require an approved template, a verified sending domain, and the existing application or Stripe proof before a message can be queued. All three collections accept limit=1..100 (default 50), after= for the next page, or before= for the previous page. Supply only one cursor. Results are newest first with stable timestamp/ID ordering and {object:"list",data,has_more}. Invalid or inaccessible cursors return 400. Event reads/list omit evidence. Missing credentials return 401, insufficient management scope 403, inaccessible event IDs 404, and malformed IDs 400. Unrestricted keys can also see account_verification and commissioning sources; domain-scoped keys only see events tied to their domain. The Node client exposes `transactional.catalog()`, provider/integration `list()`, and event `list()`, `get()`, and `revoke()` methods. The Python client mirrors these resources dynamically. ## Independent Stripe evidence POST /v1/transactional/providers accepts {domain_id,provider:"stripe",restricted_key}. Use an rk_live restricted key with read access to Events, Charges and Checkout Sessions. Credentials are encrypted, never returned, and used only for GET requests to api.stripe.com. Full-access key/session required for connection management. DELETE /v1/transactional/providers/{provider_connection_id} revokes the connection and its authorizations. payment.receipt requires charge.succeeded, PAYMENT equal to the ch_ ID, live/captured/successful/positive-value/unrefunded payment, and exact provider-record recipient. Emailer API retrieves the event and current charge. order.confirmed requires a completed paid Checkout Session in payment mode, positive total, exact customer email, and ORDER equal to its cs_ ID. Supported source events: checkout.session.completed and checkout.session.async_payment_succeeded. Test, free, incomplete, stale and mismatched transactions are rejected. The event must be no older than 15 minutes. Evidence is stripe_verified; no financial transaction is created by verification. Other events use POST /v1/transactional/integrations with a publicly routable HTTPS callback on the verified sending domain. A nonce-bound HMAC request and response must match the actual event and customer in the application's database. This evidence is application_attested, not independent proof. Financial templates cannot use this weaker path. Event authorizations last at most one hour and can authorize one email. Limits: 60 verification requests/minute/account and five active integrations/provider connections. Repeated provider object IDs cannot create additional messages through connection rotation. ## Analytics, complaints and safety GET /v1/emails/metrics: cohort totals and hourly/daily/weekly/monthly groups, domain/email filters, delivery outcomes, bounce classes, total/unique open and click observations, proxy/automation indicators, coverage and rates. Maximum 10,000 groups. Full-access key or session required. /analytics provides charts, domain filters and CSV export. GET/PATCH /v1/analytics/settings controls opens/clicks for future eligible deliveries. Verification, reset and security messages are excluded. Query-string/fragment links are never rewritten. Tracking links last 30 days. Repeated observations are deduplicated per link per minute, capped at 1,000/link. Privacy services and scanners can trigger requests; unclassified does not mean human. Historical untracked mail has null engagement, never fabricated zeroes. Rates document their denominators; unavailable measurements are null. Supported signed outgoing webhooks include email.delivered, email.deferred, email.bounced, email.complained, email.opened and email.clicked. Engagement webhooks report the first observation per recipient and event. Delivery and engagement history is available per email. A complaint suppresses the recipient; during launch any complaint or a 5% bounce rate after 100 relay acceptances in 24 hours holds the affected account for review. Node health and durable feedback failures also stop dispatch. Yahoo ARF reports must pass the dedicated arf.mail.yahoo.com DKIM signature check and match an immutable dispatch ID. Yahoo domain enrollment is still required and not confirmed; Microsoft and Gmail feeds are not enrolled. Received complaint counts are incomplete provider coverage, not spam-folder placement. Operational alert detection runs separately from the app; sending notifications requires an operator-configured destination. Completed email bodies/attachments expire after 30 days. Pending and uncertain messages are preserved. Detailed engagement events last 90 days; aggregate counts, delivery identities, suppressions and idempotency records remain. Logical storage limits and physical free-space guards apply before admission. ## SDKs and examples Node: npm install https://emailerapi.com/sdk/amgmail-sdk-0.13.1.tgz Python: python -m pip install https://emailerapi.com/sdk/amgmail-0.4.1-py3-none-any.whl Source archive: https://emailerapi.com/sdk/amgmail-0.4.1.tar.gz Install these versions from the direct downloads above. Node 0.13.1 and Python 0.4.1 are not published on npm or PyPI. Clients expose transactional.catalog, transactional.providers, transactional.integrations, transactional.events (create/list/get/revoke), transactional.templates, emails.validate, emails.send, emails.metrics and analytics.settings. Copy complete Stripe helpers from https://emailerapi.com/docs#stripe. Neither SDK silently retries mutations or follows redirects. Emailer API is not a drop-in replacement for every Resend feature; use the OpenAPI contract. ## Customer spam reporting Setup and Analytics expose Yahoo enrollment coverage and Gmail Postmaster v2 reporting per verified customer domain. GET /v1/reputation accepts an optional owned domain_id. POST /v1/reputation/domains/{id}/gmail or /yahoo accepts action connect, check or disconnect; full-access keys or authenticated dashboard sessions only. New verified domains automatically enter reporting setup. Yahoo enrollment requires operator evidence; customers cannot self-certify it. Managed Google verification uses exact-domain DNS TXT records or reader access. Google supplies delayed aggregate spam, feedback-group, authentication and delivery-error rates when volume permits; missing/low-volume/stale data is unavailable, never zero. Domain/IP rating categories are not exposed by the current v2 API. A server-controlled, DKIM-covered Feedback-ID identifies opaque customer/domain/template groups. Domain aggregates may include other services; only owned Emailer API groups are displayed. Reports refresh about every six hours, with 90-day daily history and CSV export. Fresh Gmail spam/group rates >=0.1% warn and >=0.3% hold the affected customer for operator review; delivery-error rates >=5% warn. Yahoo's authenticated individual complaints suppress the matched recipient and hold the customer. Reporting gaps and pending enrollments alert operations. No mailbox access, individual Gmail complainant identity or inbox-placement measurement is provided. See https://emailerapi.com/docs#reputation. Launch checklist: GET /v1/transactional/status?domain_id=DOMAIN_UUID&event=account.verification (full-access key or dashboard session). Exact-domain, event-specific configuration, reporting coverage and delivery evidence. Read-only: no messages, event grants, provider requests or quota reservations. Configuration completion does not authorize a message or guarantee capacity. See /docs#onboarding. Customer onboarding wizard: https://emailerapi.com/onboarding New signups open the six-step wizard automatically. It guides DNS, owner verification, approved template, application or Stripe connection, domain-scoped sending key and launch review. Progress uses current tenant/domain/event evidence. Finishing setup does not send email or establish delivery. Consumer domain: https://emailerapi.com. Existing AMG Mail accounts and API keys remain valid. Published package names stay @amgmail/sdk (Node) and amgmail (Python). Configure Node baseUrl or Python base_url to https://emailerapi.com/v1. ## Customer onboarding assistant Customers can finish setup at https://emailerapi.com/onboarding with the built-in Emailer API helper, without an external AI account. Sign in using an email login link or configured Google login; team naming is deferred. Ask which email they want to send. Saved domain, event, framework and verified checklist are shared between site and external assistants. Optional account-linked MCP: https://emailerapi.com/mcp (Streamable HTTP JSON; OAuth PKCE S256). Metadata: https://emailerapi.com/.well-known/oauth-protected-resource/mcp and https://emailerapi.com/.well-known/oauth-authorization-server. Register the documented ChatGPT or Claude callback, authenticate the customer, request onboarding:read and optionally onboarding:write, and use the exact MCP URL as OAuth resource. Grants are revocable in Connections. Tools: get_onboarding_state, select_email_type, add_sending_domain, select_sending_domain, check_domain_dns, install_approved_template, prepare_dns_changes, get_integration_code. Tools never return credentials or send mail. Cloudflare credentials belong only in the secure site field. DNS changes require customer review and application on Emailer API; an MCP client may only prepare a plan. Framework files support Node.js, Next.js, Express and Python. For non-payment mail, callbacks must be hosted on the exact verified sending domain and check actual active-customer/event records before signing. Examples refuse unimplemented event lookups. Implement and deploy these customer-specific checks; do not claim a generated starter is a working integration. Preserve all transactional safeguards and require review before an actual send. ## Free for Life plan The Free for Life plan costs $0 per month with no trial expiry, automatic paid upgrade or paid overage. Published account allowances and shared sending capacity still apply; this is not unlimited sending. Higher free allowances are planned but unavailable until published at https://emailerapi.com/pricing and reflected in the account dashboard. ## Free growth roadmap The planned maximum is up to 50,000 sends/day, free, after strict warm-up, pristine evidence-backed sending history, human review and provisioned capacity. This level is not available today. There are no automatic increases or guaranteed upgrade dates. Missing or stale evidence is unavailable, not proof of good quality. Read https://emailerapi.com/growth and the growth object in GET /v1/usage. Do not present proposed stages as active quotas, unlimited capacity or superior inbox placement. ## Reviewed answers and implementation guides Public guides provide direct answers, source references and review dates. Use the current API documentation for exact contracts. - [Developer event analytics for a transactional email API](https://emailerapi.com/guides/404-and-utm-validation): Measure documentation interest, verified setup, queue acceptance and later delivery outcomes without collecting API keys, message bodies or customer identifiers. - [How to send an account verification email with an API](https://emailerapi.com/guides/account-verification-email-api): Connect an account-verification email to a real signup event with a verified domain, approved template and server-side API key. - [How to add email to an AI-built app without exposing API keys](https://emailerapi.com/guides/add-email-to-ai-built-app-securely): A practical checklist for connecting an AI-generated app to transactional email: server-side secrets, genuine event checks and a reviewed first send. - [Appointment confirmation email API integration: a practical checklist](https://emailerapi.com/guides/appointment-confirmation-email-api): Send appointment confirmations from a real booking event with a verified domain, approved template and safe retry behavior. - [How approved transactional email templates work in an API](https://emailerapi.com/guides/approved-transactional-email-template): Choose a fixed reviewed template, supply constrained variables and keep edits separate from send authorization. - [How to cancel a scheduled email API request](https://emailerapi.com/guides/cancel-scheduled-email-api): Cancel an eligible scheduled message while preserving its audit trail and avoiding a duplicate replacement send. - [Can ChatGPT or Claude help set up transactional email?](https://emailerapi.com/guides/chatgpt-claude-email-setup-mcp): What Emailer API’s optional ChatGPT and Claude connections can help with, how account linking works and which setup actions stay in your account. - [Receipts, resets or confirmations: choose your first business email](https://emailerapi.com/guides/choose-first-transactional-emails): Choose your first transactional email by the customer action it supports. A practical checklist for receipts, password resets and appointment confirmations. - [Consent-safe developer analytics with Microsoft Clarity masking](https://emailerapi.com/guides/clarity-consent-masking): Implement consent-safe GA4 and Microsoft Clarity measurement for developer journeys while masking text and excluding customer secrets. - [Developer event analytics for a transactional email API](https://emailerapi.com/guides/developer-event-analytics): Measure documentation interest, verified setup, queue acceptance and later delivery outcomes without collecting API keys, message bodies or customer identifiers. - [Email API returns 202 but the email is not delivered: what to check](https://emailerapi.com/guides/email-api-202-accepted-not-delivered): What HTTP 202 means in Emailer API, which delivery signals to inspect next and why a queued response does not establish inbox placement. - [What to measure before you scale a transactional email API](https://emailerapi.com/guides/email-api-conversion-tracking): A practical measurement guide for transactional email integrations: separate documentation interest, verified setup, queue acceptance and later delivery outcomes. - [Can you add an email API without changing Google Workspace MX?](https://emailerapi.com/guides/email-api-dns-with-google-workspace): Keep Google Workspace receiving mail while adding a sending API. Understand MX, SPF, DKIM and the exact domain needed for event verification. - [Email API event idempotency: choose stable keys for safe retries](https://emailerapi.com/guides/email-api-event-idempotency): Design stable event and idempotency identifiers so timeouts and retried requests do not create duplicate transactional emails. - [Node.js transactional email API integration: a production checklist](https://emailerapi.com/guides/email-api-node-integration): Connect a Node.js backend to Emailer API with raw-body signature checks, scoped keys, validation and idempotent retries. - [Python transactional email API integration: a safe first workflow](https://emailerapi.com/guides/email-api-python-integration): Connect a Python backend to Emailer API with server-side credentials, event verification and a validation-first send path. - [How to use domain-scoped email API access](https://emailerapi.com/guides/email-api-sender-scope): Restrict a sending key to one verified domain, keep it off the browser and rotate access without changing tenant ownership. - [How to suppress a bounced recipient in an email API](https://emailerapi.com/guides/email-api-suppress-bounced-recipient): Handle bounce and complaint signals with tenant-scoped suppression records and no blind resend loop. - [Email API webhook retry handling: make callbacks safe to repeat](https://emailerapi.com/guides/email-api-webhook-retry): Build a webhook consumer that verifies signatures, deduplicates delivery IDs and finishes work within the callback contract. - [Email API webhook signature verification: verify before processing](https://emailerapi.com/guides/email-api-webhook-signature-verification): Verify signed delivery webhooks against the raw request body, reject replays and keep webhook status separate from inbox placement. - [Free email API for AI-built apps: what to check before choosing](https://emailerapi.com/guides/free-email-api-for-ai-built-apps): Choosing email for an app built with AI? Compare backend access, supported messages, domain setup and real free-plan capacity before you connect. - [Developer event analytics for a transactional email API](https://emailerapi.com/guides/ga4-cache-busted-validation): Measure documentation interest, verified setup, queue acceptance and later delivery outcomes without collecting API keys, message bodies or customer identifiers. - [Developer event analytics for a transactional email API](https://emailerapi.com/guides/ga4-debug-mode-validation): Measure documentation interest, verified setup, queue acceptance and later delivery outcomes without collecting API keys, message bodies or customer identifiers. - [Developer event analytics for a transactional email API](https://emailerapi.com/guides/ga4-debug-verification-receipt): Measure documentation interest, verified setup, queue acceptance and later delivery outcomes without collecting API keys, message bodies or customer identifiers. - [Developer event analytics for a transactional email API](https://emailerapi.com/guides/ga4-debugview-event-validation): Measure documentation interest, verified setup, queue acceptance and later delivery outcomes without collecting API keys, message bodies or customer identifiers. - [Developer event analytics for a transactional email API](https://emailerapi.com/guides/ga4-live-debug-validation): Measure documentation interest, verified setup, queue acceptance and later delivery outcomes without collecting API keys, message bodies or customer identifiers. - [Password-reset email in Next.js: a tested event-verification example](https://emailerapi.com/guides/nextjs-password-reset-email): Download a runnable Next.js example that checks real customer events, validates password-reset email and keeps sending separate from preparation. - [Order confirmation email API: keep receipts tied to real orders](https://emailerapi.com/guides/order-confirmation-email-api): Connect order confirmations to a durable order record and keep payment verification, template approval and later delivery states distinct. - [Does a paid booking need a receipt, an appointment confirmation, or both?](https://emailerapi.com/guides/paid-booking-receipt-or-appointment-confirmation): A small-business checklist for separating payment evidence from confirmed bookings, choosing the right Emailer API workflow and handling incomplete transactions. - [Password reset email not arriving: an app-owner checklist](https://emailerapi.com/guides/password-reset-email-not-arriving): Trace a missing password-reset message from the app event through validation, queue acceptance and delivery evidence without creating blind retries. - [How to retry an email API request without sending duplicates](https://emailerapi.com/guides/retry-transactional-email-api-idempotency): Handle email API timeouts, conflicts and capacity errors with stable event identifiers and idempotency keys, without treating a retry as a new message. - [How to revoke a transactional email event authorization](https://emailerapi.com/guides/revoke-transactional-email-event): Revoke an unused event authorization when an application action is canceled, while preserving the audit record and tenant boundary. - [Rotate email API credentials without breaking your sending service](https://emailerapi.com/guides/rotate-email-api-access-without-downtime): Use a staged server-side key rotation with a controlled verification request and a clear rollback path. - [Schedule a transactional email with an API](https://emailerapi.com/guides/schedule-transactional-email-api): Use a future schedule only for a real customer event, preserve idempotency and keep cancellation separate from delivery state. - [How to send a sign-in alert email from an API](https://emailerapi.com/guides/sign-in-alert-email-api): Design a sign-in alert workflow with a genuine security event, a reviewed template and delivery evidence that stays separate from authentication logic. - [How to send Stripe receipt emails without duplicate messages](https://emailerapi.com/guides/stripe-payment-receipt-email-without-duplicates): Map Stripe payment and checkout events to the right receipt, verify real transactions and use stable identifiers to avoid duplicate email requests. - [Transactional email API audit events: what to retain](https://emailerapi.com/guides/transactional-email-api-audit-events): Use tenant-scoped event history and delivery records to explain authorization, revocation and later outcomes without exposing secrets. - [Transactional email API cursor pagination: read large histories safely](https://emailerapi.com/guides/transactional-email-api-pagination): Use stable after and before cursors, bounded page sizes and tenant-scoped reads for transactional events and integrations. - [Validate an email API request before sending](https://emailerapi.com/guides/validate-email-api-request-before-send): Use read-only validation to catch domain, template, event, quota and storage blockers before a transactional send reserves resources.