For when sending logic belongs in product code rather than behind an SMTP integration nobody wants to maintain. The API is plain REST over HTTPS — Bearer auth, predictable status codes, typed webhooks signed with HMAC-SHA256. Idempotency keys mean retries don't double-send. SDKs cover Python, Node.js, PHP, Ruby, Go, Java and C#. Every plan ships with dedicated IPs (no add-on tier, no minimum-volume gate) and 30-to-90-day message log retention depending on plan. Same Stockholm team that's been running email infrastructure since 2003.
For when email is part of the product, not a thing the ops team handles
Email API is the right shape when the sending logic belongs inside the application code. The trigger comes from product behaviour — someone resets their password, an order ships, a 2FA code expires — and the message that goes out should be observable, retryable, and accountable from inside the same codebase that fired it. SMTP can do this, but the integration ergonomics are wrong: cleartext-ish protocol, opaque deferred queues, no structured event feedback, no idempotency story. A REST API with typed webhooks fixes those problems specifically.
Teams searching for a transactional email API or an email API for SaaS are optimising for developer ergonomics and observability, not for the lowest possible per-thousand rate. We're built around that — dedicated IPs at the Starter tier (no add-on math), typed HMAC-signed webhooks, idempotency keys that most competitors haven't bothered to implement, SDKs across the seven languages most product teams actually use, message retention measured in tens of days instead of three. And an EU operator that's been around long enough to remember when DKIM was new.
What's in every plan
REST over HTTPS
Plain JSON in, plain JSON out. Bearer auth in the Authorization header. Predictable HTTP status codes — 2xx for success, 4xx for client error, 5xx for our problem. Any language with an HTTP client can talk to it directly.
Dedicated IP addresses
Ten to twenty IPs assigned only to your account, depending on plan. No shared pool, no reputation borrowed from other senders, no upsell tier where the dedicated IPs suddenly cost extra.
Typed webhook events
Nine event types — delivered, opened, clicked, bounced (hard/soft), complained, unsubscribed, deferred, dropped, rejected. JSON payload, HMAC-SHA256 signature, exponential backoff retry for 24 hours if your endpoint is down. The payload schema is versioned.
Idempotency keys
Pass an Idempotency-Key header on a send request and the API deduplicates retries within a 24-hour window. Safe to retry on network failures without firing two password resets, two receipts, or two 2FA codes — the kind of duplication that ends in support tickets.
Server-side templates
Mustache-syntax templates with variable substitution, conditionals, loops and partials. Edit from the dashboard or push through the API alongside application deploys for version-controlled template management.
Long message retention
30 days on Starter, 60 on Growth, 90 on Scale, custom available beyond that. For comparison: Postmark defaults to 45 days, SendGrid to 3. The shorter retention is fine until a customer support ticket from week three needs the actual delivery log.
Three plans plus a Custom quote
The €469 starting price covers what dedicated infrastructure with a real API surface actually costs to run — no shared-pool subsidies that get clawed back later. Included at Starter: ten dedicated IPs, the full SDK set, webhooks with proper retry, idempotency keys, server-side templates, and 30 days of message log retention. Try assembling the same configuration on Postmark or SendGrid and the math comparison becomes uncomfortable for them, fast.
The pricing premium over the SMTP Relay plans of the same volume reflects the real engineering surface of the API: SDK maintenance across seven languages, webhook delivery infrastructure with retry and signing, idempotency tracking, template engine, longer message retention, and dashboard observability. If your application already speaks SMTP and webhook events are not part of the requirement, the SMTP Relay path is cheaper for the same dedicated IP allocation. If the product needs structured request/response, event-driven workflows and developer ergonomics, the API surface is where the money goes. Annual prepayment qualifies for a 10% discount across all three published plans.
Why dedicated IPs cost real money — and why we include them anyway
The transactional email industry has built a quiet upsell into shared-pool pricing: low headline rate, then dedicated IP add-ons at $30 to $50 per IP per month when you eventually realize you need them. Postmark requires 300,000 monthly emails before dedicated IPs become available at $50 per IP. SendGrid offers them free only above 100,000 monthly emails on Pro plans. Mailgun bundles them only at the Scale plan ($90/month). To match the 10 dedicated IPs included in the Authorize Hosting Email API Starter plan, the equivalent Postmark configuration is base + 10 × $50 = at least $500 per month just in IP add-ons, before any sending volume. The Authorize Hosting price is €469. Including dedicated IPs from day one isn't a value-add gimmick; it's an honest reflection of what serious transactional infrastructure costs.
How this stacks up against the alternatives
The transactional email API market reshuffled visibly through late 2025 and early 2026. SendGrid retired its permanent free tier in May 2025. Mailgun doubled its pay-as-you-go pricing in December 2025. Resend gained mindshare on the back of React Email integration and a generous 3,000-email free tier, though it's also the youngest infrastructure in this category. Postmark continues to sell dedicated IPs as paid add-ons rather than including them. Here's the dedicated-IP-equivalent configuration at the major providers as of April 2026:
Email API with dedicated IPs — equivalent configuration comparison, April 2026
Provider
Base plan
Dedicated IPs
Webhooks
Idempotency
Log retention
EU operator
Authorize Hosting Starter
€469/mo all-in
10 included
Typed, signed, retry 24h
Yes (header)
30 days
Yes — Sweden
Postmark Pro
$16.50/mo (10k emails)
$50/IP/mo (req. 300k+)
Standard event set
No
45 days default
No — US
SendGrid Pro
$89.95/mo (100k/mo)
Free above 100k/mo
Long event list, plan-tiered
No
3 days (paid: 30 days)
No — US
Mailgun Foundation
$35/mo (50k/mo)
Add-on above 50k/mo
5-API architecture
No
1 day default ($49+ add-on)
EU region available
Resend
$20/mo (50k/mo)
Add-on, limited
Standard set
No
3 days
No — US
Amazon SES
$0.10 per 1,000
$24.95/IP/mo
SNS-based, AWS-native
No
Configurable via S3
EU regions available
Once the math is done, the shape of it is consistent. Our €469/mo reflects what dedicated infrastructure with a complete API surface actually costs to run. The cheaper alternatives in this category each leave something out: dedicated IPs (which most serious senders eventually need), idempotency keys (which makes safe retries the application's problem instead of the platform's), reasonable log retention (which turns three-week-old support tickets into guesswork), or EU operator presence (which complicates GDPR posture for European data subjects). None of those omissions is wrong in isolation. Bundling all four into the entry tier is what the transactional email market quietly does.
Sending an email, in a few different languages
The API is plain REST over HTTPS, Bearer auth in the header, JSON in the body. Below are minimal send examples in the languages most product teams reach for day-to-day. SDKs for Python, Node.js, PHP, Ruby, Go, Java and C# wrap these calls in idiomatic native interfaces — but everything below is also pure HTTP that any language with an HTTP client can replicate.
Rubyrequire "authorize_hosting"
client = AuthorizeHosting::Client.new(
api_key: ENV.fetch("AUTHORIZE_API_KEY")
)
response = client.messages.send(
from: "no-reply@yourdomain.com",
to: ["customer@example.com"],
subject: "Your password reset link",
html: "<p>Click here to reset.</p>",
idempotency_key: SecureRandom.uuid
)
puts response.message_id
Every successful send returns a message ID that can be used to look up delivery status, event history and webhook confirmations. Failed sends return structured error objects with both a machine-readable code and a human-readable message — no silent failures, no parsing of opaque SMTP response strings.
Webhook events — the complete set
The webhook surface is where Email API earns its keep over a raw SMTP relay. Every meaningful event in a message's lifecycle gets delivered to your endpoint as a signed JSON payload, with retry semantics designed to survive transient outages on your side. The full event set:
Delivery and engagement events
delivered
Message was accepted by the recipient's mail server. The closest thing email has to a delivery receipt — does not guarantee inbox placement, but does guarantee the recipient's MX accepted the message.
opened
Recipient opened the message (tracked via 1×1 pixel; subject to image-loading behaviour at the recipient).
clicked
Recipient clicked a tracked link in the message. URL is included in the event payload.
unsubscribed
Recipient clicked an unsubscribe link or used List-Unsubscribe headers. Auto-applied to suppression list.
Failure events
bounced
Message was rejected by the recipient's mail server. Payload includes hard/soft classification, SMTP response code and reason. Hard bounces auto-suppress.
complained
Recipient marked the message as spam (FBL signal from AOL, Yahoo, Hotmail). Auto-suppresses the recipient and counts toward complaint rate metrics.
deferred
Message was temporarily rejected (4xx SMTP response). Retry is automatic; this event is informational. Repeated defers eventually convert to bounced.
dropped
Message was not sent because the recipient is on a suppression list (previous bounce, complaint or unsubscribe). Useful for surfacing list hygiene problems.
rejected
Message was rejected at submission (invalid format, missing required field, malformed recipient). Triggered before any delivery attempt.
Webhook payloads are signed with HMAC-SHA256 using a per-account secret. Verification is a single line of code in any language. Failed webhook deliveries (non-2xx response, timeout, network error) are retried with exponential backoff over 24 hours before being abandoned, and the full retry history is visible in the dashboard.
Where the API sits between your application and the inbox
Email API architecture — application to inbox, with event feedbackYour application calls the REST API with structured JSON. The API handles authentication, queueing, throttling and DKIM signing, and the actual outbound delivery happens from your dedicated IPs to the receiver's mail server. Webhook events flow back to your endpoint asynchronously — signed with HMAC-SHA256, retried with exponential backoff if your endpoint is down. The application never has to parse an SMTP response code or guess what happened to a message.
The product shapes that fit this
SaaS product notificationsAccount creation, email verification, password resets, plan changes, two-factor codes — anything triggered by application state and benefiting from typed event webhooks back to product code.
Subscription billing eventsStripe-style webhooks need outbound mail with the same event-driven discipline. Receipt sent, subscription renewed, payment failed, dunning escalation — each tied to product state with idempotent retries.
Marketplace and platform sendingMulti-tenant platforms sending on behalf of vendors, marketplaces routing notifications between buyers and sellers, white-label SaaS that needs per-customer template control.
Workflow automation toolsn8n, Zapier-style integrations, custom backend workflows, event-driven architectures where mail is one channel among many and structured payloads matter more than universal SMTP compatibility.
Mobile and web app notificationsiOS/Android apps that send transactional mail through a backend, React/Vue frontends with API-first architectures, JAMstack sites that hit serverless functions for outbound.
Internal developer toolsBuild notifications, deployment alerts, monitoring summaries, error reports from observability stacks that prefer JSON over SMTP and need to know whether a message actually reached its target.
When this beats SMTP Relay — and when it doesn't
They're different products solving different problems. SMTP Relay is the better fit when the application already speaks SMTP and the priority is keeping that integration while improving delivery — billing systems, ERPs, off-the-shelf SaaS, helpdesk tools, most legacy applications. Email API takes over when sending logic should live deeper in product code: when you want event webhooks tied to application state, when idempotency keys matter for retry safety, when the messaging surface should look like the rest of your modern HTTP stack rather than like a conversation with an old protocol. Plenty of teams end up using both — SMTP Relay for the off-the-shelf tools that already speak SMTP, Email API for the product's own outbound code. The decision is rarely either-or.
Technical specifications, briefly
Endpoint
https://api.authorizehosting.com/v1/ — versioned URL prefix; v1 is the current stable version.
Authentication
Bearer token in Authorization header. API keys can be rotated, scoped per environment, or revoked from the dashboard. No basic auth, no query-string credentials.
Request format
JSON request body, Content-Type: application/json. Maximum request size 50 MB (52,428,800 bytes) including attachments. UTF-8 encoded.
Response format
JSON response body with predictable schema. HTTP status reflects outcome (2xx success, 4xx client error, 5xx server error). Error responses include both machine-readable code and human-readable message.
Idempotency
Idempotency-Key header (UUID recommended) deduplicates retries within a 24-hour window. Critical for production systems with retry logic.
Batch sending
Up to 500 personalized messages per batch call with template variable substitution. The right primitive for transactional fan-out (notification digests, status updates to multiple recipients).
Webhook signing
HMAC-SHA256 signature in X-Authorize-Signature header. Secret is per-account, configurable from dashboard. Verification is a single line of code in any language.
Webhook retry
Exponential backoff up to 24 hours on non-2xx response. Failed deliveries logged in dashboard. Webhooks can be replayed manually from the message detail view.
Migrating in from SendGrid, Mailgun, Postmark or Resend
Most teams arriving here are migrating off something else. SendGrid migrations have been particularly common since the May 2025 free-tier retirement triggered widespread evaluation of alternatives. The migration pattern follows the same shape as the SMTP Relay path: dedicated IPs need to warm up before they carry full production volume, no matter how clean the sending domain reputation already is at the old provider.
The right way is parallel sending during the warmup. Keep the existing API live for the first 14 to 21 days of the new dedicated IPs' life. Route a small fraction of traffic through the new endpoint, starting with low-risk message types — internal alerts, low-engagement digests — and scaling up to the high-stakes ones (password resets, 2FA codes) once the initial reputation has settled. Ramp gradually. The webhook and idempotency surface makes A/B routing during the transition clean: the same idempotency key sent to both providers during the overlap won't produce duplicates, because each side dedupes independently.
A few specifics by source provider. From SendGrid or Mailgun, the API shape is similar enough that a thin wrapper can route between both during cutover. From Postmark, the main schema difference is PascalCase property names (From, To, Subject) versus our camelCase / snake_case — a minor adapter layer handles the translation. From Resend, the API surface is small enough that direct cutover is usually feasible right after warming completes.
Common questions about Email API
FAQ
The questions that come up most often before someone signs
What is a transactional Email API?
It's an HTTP interface that lets your application send email with one REST call instead of opening an SMTP connection and reasoning about an old protocol. The provider handles authentication, queueing, retry, throttling, DKIM signing, bounce processing, webhook delivery — the operational layer that SMTP makes you handle yourself or guess at. The win over SMTP is structured JSON in and out, idempotency keys for retry safety, and event webhooks for opens, clicks, bounces, complaints and deliveries fed back to your code in the same shape it expects everything else.
How is your Email API different from SendGrid, Postmark or Mailgun?
The most visible difference is the dedicated IPs — they ship with the entry plan, not as a paid add-on after signup. Postmark charges $50 per IP per month and won't sell them at all unless you're hitting 300,000+ monthly sends. SendGrid offers free dedicated IPs only above 100,000 monthly. Mailgun bundles dedicated IPs only at the Scale plan ($90/month base, with the IPs themselves still limited). Our Starter is €469/month with ten dedicated IPs in the box, full SPF/DKIM/DMARC alignment, and an EU operator that's been in Stockholm since 2003.
Does the API include SDKs?
Yes — Python, Node.js, PHP, Ruby, Go, Java, C#, plus a generic curl-based reference for everything else. All maintained, all documented. The API itself is plain REST over HTTPS, so any language with an HTTP client can call it directly without an SDK if that's preferable.
What webhook events does the API send?
Nine types: delivered, opened, clicked, bounced (with hard or soft classification), complained (FBL), unsubscribed, deferred, dropped (suppression list match), and rejected (SMTP-level reject). Payloads are JSON, signed with HMAC-SHA256 so you can verify they're real, and retried with exponential backoff for up to 24 hours if your endpoint returns anything other than 2xx.
Does the API support idempotency keys?
Yes. Pass an Idempotency-Key header on any send request and the API deduplicates retries within a 24-hour window. This matters for safely retrying failed network calls without firing two password resets, two receipts, or two 2FA codes — the kind of duplication that turns into a support ticket. Most competing APIs don't implement idempotency at all, which means safe retries become your problem instead of theirs.
Can the API send to multiple recipients per call?
Yes, two modes. Single-message multi-recipient sends one message visible to all recipients — like a normal To/Cc/Bcc email. Batch mode accepts up to 500 individual recipients per call, each receiving a personalised message via template variable substitution. Batch mode is the right primitive for transactional fan-out (notification digests, status updates to lists of recipients).
What kinds of messages fit Email API best?
The transactional shape: password resets, verification flows, billing events, account alerts, receipts, 2FA codes, order confirmations, shipping updates, product notifications. They all get triggered directly by application behaviour, and they all benefit from the event-level webhooks tied back to product code — so when something fails, you find out from your own application rather than from a customer support ticket two days later.
When is SMTP Relay the better fit?
When the product or system already sends through SMTP and the priority is keeping that integration while improving delivery. Email API earns its place when sending logic should live deeper in product code and your developers want event webhooks, idempotency, and structured request/response handling — none of which SMTP gives you cleanly.
Does the Email API support templates?
Yes — stored server-side, referenced by ID in the send request. The template engine is Mustache-syntax with variable substitution, conditionals, loops and partials. Templates can be edited from the dashboard or pushed through the API alongside application deploys, which lets you version-control them in the same repo as the code that fires them.
What's the API rate limit?
It scales with the plan: Starter at 600 requests per minute, Growth at 1,800 per minute, Scale at 6,000 per minute. Custom plans negotiate from there. The limits apply to the API endpoint itself; outbound delivery to receivers is shaped separately by per-receiver throttling rules so you don't accidentally trigger Gmail's complaint thresholds during a burst.
How long are message logs retained?
30 days on Starter, 60 on Growth, 90 on Scale, custom available beyond that. For comparison: Postmark defaults to 45 days; SendGrid defaults to 3 days, with 30 days as a paid upgrade. The longer retention is part of why dedicated infrastructure costs what it does — when a customer ticket from week three needs the actual delivery log to investigate, the 3-day default isn't going to help.
Customer engagements
Five deployments. Five different reasons.
Real engagements, names withheld, technical details intact. Each one shows the API solving a different operational problem — not a single "we improved deliverability" copy-paste across five companies.
01
French marketplace — event-driven sends from a Node.js backend
Vertical marketplace for professional equipment, based in Paris
Context
Sending logic had spread across SQS workers, Lambda triggers and a legacy cron job that nobody on the team had touched in two years. Three subsystems all claimed responsibility for every transactional message, which meant nobody actually owned reliability — when something failed, the postmortem started with "wait, which one of those even sent this?"
Implementation
Everything sending consolidated behind a single Email API integration with one SDK wrapper. Webhooks for bounce, complaint and delivery routed straight into the existing event bus. IPs warmed across 21 days while the legacy paths kept running in parallel as a safety net.
Outcome
Message-level observability hit 100%. Time-to-detect a sending issue went from "next morning's standup" to under four minutes via Slack alerts on webhook anomalies. Engineering effort to maintain sending infrastructure: roughly halved.
02
Swedish SaaS — transactional plus product update digests
Project management SaaS in Stockholm, ~12k paying teams
Context
Mixed workload — high-frequency transactional notifications next to lower-frequency promotional digests — all sharing the same sending IPs at the previous provider. A digest send would occasionally degrade transactional delivery for several hours afterwards. Customer-reported reliability tickets accumulated.
Implementation
Email API plan with two separate IP pools, one for transactional, one for promotional. Stream isolation enforced at the API level via a category parameter on each send. The webhook stream wired into existing Datadog dashboards for SLO tracking.
Outcome
Transactional inbox placement now sits consistently at 97-99% regardless of when digests go out. Three customer-reported reliability tickets that had been open for months got closed in the first quarter after migration.
03
Italian travel — booking confirmations and itinerary updates
Booking platform for boutique European hotels, headquartered in Milan
Context
Booking confirmations needed to arrive within 30 seconds for 96% of transactions to meet the customer's internal SLA. Previous provider averaged 45 seconds with frequent 2-3 minute outliers during peak booking windows.
Implementation
Email API on three transactional-prioritised IPs. Implemented idempotency keys on all sends to handle retry storms safely. Detailed delivery tracking exposed to internal support team via a thin admin UI.
Outcome
P95 confirmation delivery: 12 seconds. P99: 28 seconds. Support contacts about missing confirmations dropped 71%.
04
Polish gaming — in-game notifications and account recovery
Mid-tier studio publishing competitive multiplayer games, based in Warsaw
Context
Account recovery emails were taking 3-15 minutes to arrive on Gmail, generating support tickets where players assumed their account was lost. Volume: about 40k recovery sends per month, with seasonal peaks tied to game updates.
Implementation
Email API integration replaced direct SMTP from game servers. Two dedicated IPs warmed during a low-volume period before the next major patch release. Bounce webhooks fed into the customer's anti-fraud system.
Outcome
Median recovery email arrival: 6 seconds. Support tickets about lost accounts: down 80%. As a side benefit, the bounce stream identified ~3k stale accounts that the team could clean from the active player base.
05
UK CRM platform — customer-facing email send-as-feature
Mid-market CRM provider in London, white-label sending offered to 800+ business customers
Context
Their own customers send through the platform under their own domains. The previous infrastructure failed when one customer's reputation issue contaminated shared sending IPs, blocking deliverability for all 800+ tenants for several days.
Implementation
Email API with per-customer IP isolation via dynamic IP assignment. DKIM signing infrastructure that handles 800+ customer domains via API-managed key rotation. Detailed per-tenant deliverability dashboards exposed to platform users.
Outcome
One bad sender no longer affects others — the issue is contained to that tenant's IP pool. Platform-wide deliverability SLO (98%+) now consistently met. The dashboard became a marketed feature that closed enterprise deals.
All engagements anonymised at the customer's request. Industry descriptors, volumes, and technical details reflect actual deployments. Specific company identifiers have been withheld.
Related services
Related services that often enter the conversation
Email API rarely lives in isolation. Teams comparing integration paths usually end up choosing between compatibility, application control and infrastructure separation.
Worth considering when product-led sending also needs stronger isolation, custom resources or more control over the environment.
Where to look next
Three places that usually answer the next question
Most API buyers want one of three things: tighter application control, a simpler SMTP-compatible path, or more isolation around the sending environment. Each of these covers one.
The natural follow-on if product-led sending also needs stronger isolation, custom resources, or a clearer infrastructure boundary than a managed API gives you.
