빠르게 출시하는 팀을 위한 실용 API
OTP, 비밀번호 재설정, 계정 알림, 청구서, 라이프사이클 메시지를 하나의 API로 발송하세요. Sendarix는 취약한 연동이 아니라 규모에서도 예측 가능한 동작을 목표로 설계되었습니다.
요청 인증, 메시지 제출, 결과 추적을 일관된 파이프라인에서 처리합니다. 모든 발송은 로그, 이벤트, 웹훅으로 확인할 수 있습니다.
API calls flow through structured validation, queue management, and email routing before reaching destination servers. Delivery outcomes are surfaced via email webhooks and tracked in email analytics.
제공 내용
API는 의도적으로 단순합니다. 메시지 생성·발송, 결과 확인, 반응 자동화. 제품 팀이 신뢰성을 희생하지 않고 더 빠르게 움직일 수 있도록 돕습니다.
빠른 REST 연동
명확한 요청/응답 패턴과 현대 백엔드 서비스·내부 도구에 적합한 예측 가능한 동작.
메시지 라이프사이클 추적
수락, 전달, 바운스, 스팸 신고 상태를 추적해 제품이 실시간으로 대응할 수 있습니다.
운영 가시성
검색 가능한 로그와 이벤트 스트림으로 전달 문제 신고 시 문제 해결 시간을 줄입니다.
재구축 없이 확장
초기 부하부터 대량 트래픽까지 동일한 API 계약을 유지합니다.
템플릿 데이터 주입
동적 변수를 깔끔하게 전달해 트랜잭션 템플릿이 제품 간 일관되게 유지되도록 합니다.
멱등 발송 패턴
재시도 시 중복 발송을 방지하는 결정적 요청 처리 전략.
What Happens After an API Send Request
A successful API response is the start of the message lifecycle, not the end of it.
Validation
The system checks authentication, request shape, sender identity, and required fields before accepting the request.
Acceptance and Queueing
A successful response means the request has been accepted for processing. It does not necessarily mean the message has already been delivered to the destination server.
Delivery Processing
After acceptance, the message moves through delivery logic that may include queueing, suppression checks, routing policy, and destination-aware pacing.
Event Generation
As the message progresses, delivery events can be exposed to logs, analytics, and webhook consumers so your application can react in near real time. Monitor progression via email analytics or email webhooks.
Why Accepted Does Not Mean Delivered
A successful API response confirms that the request has been accepted into the processing pipeline. Final delivery still depends on validation, suppression checks, routing policy, provider behavior, and downstream delivery outcomes.
Email API vs SMTP Relay
Both approaches can send email, but they solve different integration needs.
Email API
Best for modern applications that want structured requests, cleaner metadata, and easier automation around delivery state. See API docs for integration details.
SMTP Relay
Best for older tools, legacy systems, or environments that already speak SMTP and need compatibility with minimal code changes. See SMTP relay for setup details.
Many teams use an email API for product-driven workflows and SMTP relay for compatibility with older tools, internal systems, or third-party applications that already speak SMTP. Check API docs for implementation, email webhooks for event handling, and email analytics for delivery visibility.
일반적인 API 흐름
한 번 구현해 모든 트랜잭션 시나리오에 재사용할 수 있는 단순한 패턴입니다.
1. 요청 제출
서비스가 수신자, 템플릿 데이터, 메타데이터가 포함된 메시지 페이로드를 게시합니다.
2. 검증 및 대기열
입력 검사, 억제 로직, 대기열 처리가 전달 단계 전에 수행됩니다.
3. 전달
메시지는 제어된 발송 동작으로 대상 제공업체로 라우팅됩니다.
4. 이벤트 소비
웹훅과 로그로 제품 상태를 업데이트하고 하위 자동화를 트리거합니다.
Real-World Scenario: Idempotent Send Request
A payment confirmation is triggered by a webhook from a payment processor. The application sends via the email API with an idempotency key. If the API call is accidentally retried due to a network timeout, the email routing layer recognizes the duplicate and returns the original queued message ID rather than queuing a second send. Delivery is confirmed via email webhooks.
Example API Request Flow
- Client sends request to API docs
- Request is validated
- Message is queued
- Delivery attempt is executed
- Events are generated and tracked via email webhooks
Note: A successful API response (e.g. 202 Accepted) means the message is queued, not delivered. Track final delivery status with email analytics or webhook events.
Example API Request and Response
Every Sendarix API call uses JSON and returns consistent response shapes. Below are the primary endpoints your integration will call most frequently.
Send Message
POST to /v1/messages with recipient, subject, and template data. Returns a message_id for correlation with downstream webhook events.
POST /v1/messages
Authorization: Bearer sk_live_...
Content-Type: application/json
{
"recipient": "user@example.com",
"subject": "Your verification code",
"template": "otp-code",
"template_data": {
"code": "847291",
"expires_in": "5 minutes"
},
"headers": {
"X-Idempotency-Key": "uuid-v4-here"
}
}
{
"message_id": "msg_abc123xyz",
"status": "queued",
"recipient": "user@example.com",
"created_at": "2026-04-19T14:30:00Z"
}
Returns a message_id and status: queued. Correlate message_id with email webhooks for delivery status.
List Messages
GET /v1/messages returns a paginated list of messages with filtering by status, recipient, and date range.
GET /v1/messages?status=delivered&limit=25 Authorization: Bearer sk_live_...
Get Message
GET /v1/messages/{message_id} returns the current state of a specific message including timestamps, recipient, and delivery outcome.
GET /v1/messages/msg_abc123xyz Authorization: Bearer sk_live_...
Cancel Scheduled Message
DELETE /v1/messages/{message_id} cancels a scheduled message before it is delivered. Returns 404 if already sent.
DELETE /v1/messages/msg_abc123xyz Authorization: Bearer sk_live_...
Add to Suppression List
POST /v1/suppressions adds an address to the suppression list to prevent future sends to that recipient.
POST /v1/suppressions
Authorization: Bearer sk_live_...
{
"recipient": "user@example.com",
"reason": "user_unsubscribed"
}
Validation, Queueing, and Delivery Lifecycle
Understanding what happens between an API call and final delivery helps you design more resilient integrations and debug issues faster.
Step 1: Request Validation
The API validates: required fields (recipient, from, subject), email address format, API key and permissions, content size limits. Validation errors return 400 or 422 immediately with a field-level error array. No message is queued until validation passes.
Step 2: Queue and Acceptance
Validated messages enter the sending queue with a queued status. A message_id is returned immediately so your application can correlate with downstream events. Queue processing is FIFO within priority tiers.
Step 3: Routing and Provider Selection
The routing layer selects the optimal sending path based on recipient domain, IP reputation, and provider performance. This is handled automatically by Sendarix infrastructure.
Step 4: Delivery Attempt
The message is delivered to the recipient's mail server. Delivery outcomes (delivered, bounced, deferred) are posted to your configured webhook endpoint. Track delivery in the email analytics dashboard.
Event Timeline
Each message generates a timeline of events: queued → accepted → delivered/bounced/deferred. You receive webhook events for each state change. Between queued and final state, multiple deferred events may fire as the system retries temporary failures.
Retry Behavior for Deferred Messages
Deferred messages (temporary provider rejection, greylisting) are retried automatically at increasing intervals: 30 seconds, 5 minutes, 30 minutes, 2 hours, 5 hours. After 6 attempts, the message is marked as permanently bounced and you receive a bounce event.
Error Handling and Retry-Safe Integration Patterns
A production-grade integration handles API errors gracefully. These patterns prevent duplicate sends, data inconsistency, and user-facing failures.
HTTP Status Code Reference
Map status codes to retry behavior:
200
— Success — no retry needed
400
— Bad request — fix payload before retrying
401
— Unauthorized — check API key, do not retry
422
— Validation failed — fix payload, do not retry
429
— Rate limited — retry after X-RateLimit-Reset
500
— Server error — retry with exponential backoff
503
— Service unavailable — retry with backoff
Idempotent Send Pattern
Pass an idempotency_key (UUID v4 recommended) in the request headers: Idempotency-Key: {uuid}. If the same idempotency_key is submitted twice within 24 hours, the API returns the original response without re-sending. This prevents duplicate sends during retry loops.
Correlating API Calls to Events
Every message response includes a message_id. Match this against the message_id in email webhooks to confirm delivery. Never assume a 200 OK means the email was delivered — a 200 confirms the message was queued.
Exponential Backoff Implementation
Use this backoff formula: delay = min(base * 2^attempt + jitter, max_delay). Recommended base: 1 second, max_delay: 60 seconds, jitter: 0-1000ms random. Always cap retries at a maximum of 5 attempts to avoid infinite loops.
Dead-Letter Handling
After exhausting retries, log permanently failed messages to a dead-letter table keyed on message_id. Inspect these periodically to identify systemic issues (bad address patterns, provider problems, template errors) and fix upstream.
Common Email API Use Cases
The Sendarix API handles all transactional email flows. These are the most common integration patterns.
One-Time Passwords (OTP)
Send time-sensitive OTP codes for login, password changes, and identity verification. OTP emails require low latency, high deliverability, and clean templates with no distracting content. Set a short TTL in your application — OTP codes are security-sensitive and should not persist in inboxes.
Password Reset Emails
Password reset links must reach users quickly and reliably. These are high-stakes flows — a missed reset email creates support tickets and churn. Pair with email webhooks to detect bounce events and alert security teams if reset emails are bouncing for active users.
Billing and Invoice Notifications
Invoice delivery, payment confirmations, and failed payment alerts drive user engagement with billing systems. Use template data injection to personalize invoice amounts and due dates. For failed payments, trigger retry logic in your system based on the bounce event.
Account Lifecycle Notifications
Welcome emails, email verification, account suspension, and deletion notices are all driven by user actions in your system. These flows work best with an idempotency key per user action to prevent duplicate sends when users trigger the same action multiple times.
System and Security Alerts
New login detected, password changed, device authorized, unusual activity alerts — these require immediate delivery to catch security incidents. Route these through your highest-priority sending path. Set up real-time email analytics alerts for spike patterns that may indicate a compromised account.
Integrate with Your Email Infrastructure
The Email API works alongside SMTP relay for legacy system migration, transactional email templates for content management, and email analytics for cross-channel performance reporting. Build a complete email stack with the API at the center.
Need SMTP configuration for a specific provider? Check our step-by-step guides for Gmail SMTP settings, Outlook SMTP configuration, Office 365 setup, Yahoo SMTP settings, and SendGrid SMTP settings.
What sets Sendarix apart: The Sendarix email API is designed around infrastructure control — routing rules, queue behavior, and delivery policy are exposed through the API, giving engineering teams programmatic access to what most platforms hide behind dashboards.
자주 묻는 질문
API와 SMTP를 함께 사용할 수 있나요?
예. 많은 팀이 애플리케이션 워크플로에는 API를, 마이그레이션 중 레거시 시스템에는 SMTP를 사용합니다.
메시지마다 이벤트 데이터를 받을 수 있나요?
예. 전달, 바운스, 스팸 신고 이벤트는 운영 및 제품 워크플로에서 사용할 수 있습니다.
대량 트래픽에 적합한가요?
예. 동일한 API 모델이 저볼륨 온보딩 단계부터 지속적인 고볼륨 발송까지 사용됩니다.
API 발송에 SPF, DKIM, DMARC가 필요한가요?
발송 도메인 인증을 강력히 권장합니다. 사서함 제공업체의 메일 평가를 개선하며 프로덕션 트래픽의 기본 기대입니다.
API 키와 권한은 어떻게 동작하나요?
환경 또는 서비스별로 키를 발급하고 키별로 수행 가능한 작업을 제한해 스테이징, CI, 프로덕션을 분리할 수 있습니다.
잘못되거나 중복된 요청을 보내면 어떻게 되나요?
API는 잘못된 페이로드에 대해 명확한 검증 오류를 반환합니다. 재시도 시에는 앱 계층에서 안정적인 식별자를 사용해 동일 사용자 대면 이메일이 중복 발송되지 않도록 하세요.
API 호출과 하류 전달을 연관시킬 수 있나요?
예. 메시지 식별자와 이벤트 타임라인으로 특정 API 제출을 수락, 전달, 바운스, 지연 결과와 연결할 수 있습니다.
비밀번호 재설정과 OTP에 이메일 API가 적합한가요?
예. 이러한 흐름은 전형적인 트랜잭션 사용 사례로, 낮은 지연, 높은 가시성, 인증·리스크 시스템과의 긴밀한 연결이 필요합니다.
API 트래픽은 HTTPS만 사용해야 하나요?
예. TLS는 전송 중 자격 증명과 메시지 메타데이터를 보호합니다. API 엔드포인트는 기타 프로덕션 비밀 표면과 동일하게 취급하세요.
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).
