Route · Email API
이메일 API
OTP, 비밀번호 재설정, 계정 알림, 청구서, 라이프사이클 메시지를 하나의 API로 발송하세요. Sendarix는 취약한 연동이 아니라 규모에서도 예측 가능한 동작을 목표로 설계되었습니다.
# 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 — 기존 통합 유지, control plane 확보 host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
안정적인 계약
빠르게 출시하는 팀을 위한 실용 API
요청 인증, 메시지 제출, 결과 추적을 일관된 파이프라인에서 처리합니다. 모든 발송은 로그, 이벤트, 웹훅으로 확인할 수 있습니다.
대표 제품 UI — 예시 데이터이며 실제 고객 지표가 아닙니다.
제공 내용
API는 의도적으로 단순합니다. 메시지 생성·발송, 결과 확인, 반응 자동화. 제품 팀이 신뢰성을 희생하지 않고 더 빠르게 움직일 수 있도록 돕습니다.
빠른 REST 연동
명확한 요청/응답 패턴과 현대 백엔드 서비스·내부 도구에 적합한 예측 가능한 동작.
메시지 라이프사이클 추적
수락, 전달, 바운스, 스팸 신고 상태를 추적해 제품이 실시간으로 대응할 수 있습니다.
운영 가시성
검색 가능한 로그와 이벤트 스트림으로 전달 문제 신고 시 문제 해결 시간을 줄입니다.
재구축 없이 확장
초기 부하부터 대량 트래픽까지 동일한 API 계약을 유지합니다.
템플릿 데이터 주입
동적 변수를 깔끔하게 전달해 트랜잭션 템플릿이 제품 간 일관되게 유지되도록 합니다.
멱등 발송 패턴
재시도 시 중복 발송을 방지하는 결정적 요청 처리 전략.
일반적인 API 흐름
한 번 구현해 모든 트랜잭션 시나리오에 재사용할 수 있는 단순한 패턴입니다.
1. 요청 제출
서비스가 수신자, 템플릿 데이터, 메타데이터가 포함된 메시지 페이로드를 게시합니다.
2. 검증 및 대기열
입력 검사, 억제 로직, 대기열 처리가 전달 단계 전에 수행됩니다.
3. 전달
메시지는 제어된 발송 동작으로 대상 제공업체로 라우팅됩니다.
4. 이벤트 소비
웹훅과 로그로 제품 상태를 업데이트하고 하위 자동화를 트리거합니다.
자주 묻는 질문
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).
관련 제품
