Route · Email API
Email API for Developers
Send transactional email from your application with a clean REST API. OTPs, password resets, order confirmations, billing alerts — all with consistent response shapes, idempotent delivery, and real-time email webhooks status updates.
# Send a critical email through a routing policy curl -sS -X POST 'https://app.sendarix.com/v1/email/send' \ -H 'Content-Type: application/json' \ -H 'X-API-Key: YOUR_API_KEY' \ -H 'Idempotency-Key: otp_8842' \ -d '{"to":"user@acme.com","template":"password_reset","routing_policy":"transactional-critical"}'
const sendarix = require("sendarix")(process.env.SENDARIX_KEY); await sendarix.email.send({ to: "user@acme.com", template: "password_reset", routingPolicy: "transactional-critical", idempotencyKey: "otp_8842" });
# Drop-in SMTP — keep your integration, gain a control plane host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
A stable contract
REST Email API Built for Developer Teams
From your first API call to production scale, the Sendarix API contract stays stable. No surprises as traffic grows, no rebuilding integration as volume increases.
Representative product UI — illustrative data, not live customer metrics.
What You Get
The API is intentionally straightforward: create and send messages, inspect outcomes, and automate reactions. This helps product teams move faster without compromising reliability.
Fast REST Integration
Clear request/response patterns and predictable behavior for modern backend services and internal tools.
Message Lifecycle Tracking
Track accepted, delivered, bounced, and complained states so your product can react in real time.
Operational Visibility
Searchable logs and event streams reduce troubleshooting time when users report delivery issues.
Scale Without Rebuilds
From early-stage workloads to high-volume flows, keep one API contract as volume grows.
Template Data Injection
Pass dynamic variables cleanly so transactional templates stay consistent across products.
Idempotent Send Patterns
Prevent duplicate sends in retry scenarios with deterministic request handling strategies.
Typical API Flow
A simple pattern your team can implement once and reuse across all transactional scenarios.
1. Submit Request
Your service posts a message payload with recipient, template data, and metadata.
2. Validate & Queue
Input checks, suppression logic, and queueing happen before the delivery stage.
3. Deliver
Messages are routed to destination providers with controlled sending behavior.
4. Consume Events
Use webhooks and logs to update product state and trigger downstream automations.
Frequently Asked Questions
Can we use API and SMTP together?
Yes. Many teams use API for application workflows and SMTP for legacy systems during migration.
Do we get event data for each message?
Yes. Delivery, bounce, and complaint events are available for operational and product workflows.
Is this suitable for high-volume traffic?
Yes. The same API model is used from low-volume onboarding phases to sustained high-volume sending.
Do we need SPF, DKIM, and DMARC for API sending?
Authenticating your sending domain is strongly recommended. It improves how mailbox providers evaluate your mail and is a baseline expectation for production traffic.
How do API keys and permissions work?
You can issue keys for different environments or services and restrict what each key can do, so staging, CI, and production stay isolated.
What happens if our integration sends invalid or duplicate requests?
The API returns clear validation errors for bad payloads. For retries, use stable identifiers in your app layer so you do not accidentally double-send the same user-facing email.
Can we correlate API calls with downstream delivery?
Yes. Message identifiers and event timelines let you connect a specific API submission to accepted, delivered, bounced, or deferred outcomes.
Is the Email API a good fit for password resets and OTP codes?
Yes. These flows are classic transactional use cases: low latency expectations, high visibility requirements, and tight coupling to your auth or risk systems.
Should we use HTTPS only for API traffic?
Yes. TLS protects credentials and message metadata in transit. Treat API endpoints like any other production secret-bearing surface.
What is the request rate limit on the Email API?
Rate limits vary by plan. Standard plans allow 1,000 requests/minute; enterprise plans support higher throughput. Rate limit headers are included in every response (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset). Exceeding the limit returns 429 Too Many Requests.
How do we handle API failures gracefully in our application?
Implement exponential backoff with jitter for retries. Treat 429 as a signal to slow down, 5xx as transient errors to retry, and 4xx (except 429) as permanent failures that should not retry. Store the message_id from successful submissions to correlate with downstream webhook events.
What is the maximum message size via API?
Messages up to 50MB total payload are accepted. For files larger than 25MB, Sendarix recommends hosting files externally and including a signed download link in the email body rather than attaching directly. Some mail servers reject messages exceeding 25MB.
Can we schedule email delivery for a future time?
Yes. Pass a scheduled_time parameter (ISO 8601 UTC timestamp) in your API request. Messages are queued and delivered at the specified time. Scheduled messages can be cancelled before delivery by calling the message cancel endpoint with the message_id.
How do we handle unsubscribe programmatically via the API?
The API provides /unsubscribes endpoints for managing suppression records. When a user unsubscribes, add them via the API to prevent future sends to that address. This integrates with the email webhooks unsubscribe event for automatic suppression list updates.
What response codes should our retry logic handle?
Handle these specifically: 200 OK (success, no retry), 400 Bad Request (invalid payload, fix before retry), 401 Unauthorized (invalid API key, do not retry), 422 Unprocessable Entity (validation error, fix payload), 429 Too Many Requests (rate limited, retry after X-RateLimit-Reset), 500 Internal Server Error (transient, retry with backoff).
Related Products
Protect critical email across every tenant.
Move your most critical stream to Sendarix this week. Keep everything else exactly where it is.
