Route · Email API
API de correo
Envíe OTP, restablecimientos de contraseña, alertas de cuenta, facturas y mensajes del ciclo de vida desde una sola API. Sendarix está diseñado para un comportamiento predecible a escala, no para integraciones frágiles.
# Enviar un email crítico mediante una 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" });
# SMTP drop-in — conserva tu integración y gana un control plane host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
Un contrato estable
Una API práctica para equipos que lanzan con rapidez
Autentique solicitudes, envíe mensajes y haga seguimiento de los resultados en una canalización coherente. Cada envío puede observarse mediante registros, eventos y webhooks.
UI de producto representativa — datos ilustrativos, no métricas reales de clientes.
Lo que obtiene
La API es deliberadamente sencilla: crear y enviar mensajes, inspeccionar resultados y automatizar reacciones. Ayuda a los equipos de producto a avanzar más rápido sin comprometer la confiabilidad.
Integración REST rápida
Patrones claros de solicitud/respuesta y comportamiento predecible para servicios backend modernos y herramientas internas.
Seguimiento del ciclo de vida del mensaje
Rastree estados aceptado, entregado, rebotado y con queja para que su producto reaccione en tiempo real.
Visibilidad operativa
Registros buscables y flujos de eventos reducen el tiempo de resolución cuando los usuarios informan problemas de entrega.
Escale sin reescribir todo
Desde cargas tempranas hasta flujos de alto volumen, mantenga un solo contrato de API a medida que crece el volumen.
Inyección de datos en plantillas
Pase variables dinámicas de forma ordenada para que las plantillas transaccionales se mantengan coherentes entre productos.
Patrones de envío idempotentes
Evite envíos duplicados en reintentos con estrategias deterministas de manejo de solicitudes.
Flujo típico de la API
Un patrón simple que su equipo puede implementar una vez y reutilizar en todos los escenarios transaccionales.
1. Enviar la solicitud
Su servicio publica una carga con destinatario, datos de plantilla y metadatos.
2. Validar y encolar
Comprobaciones de entrada, lógica de supresión y puesta en cola ocurren antes de la etapa de entrega.
3. Entregar
Los mensajes se enrutan a proveedores de destino con comportamiento de envío controlado.
4. Consumir eventos
Use webhooks y registros para actualizar el estado del producto y activar automatizaciones posteriores.
Preguntas frecuentes
¿Podemos usar API y SMTP juntos?
Sí. Muchos equipos usan la API para flujos de aplicación y SMTP para sistemas heredados durante la migración.
¿Obtenemos datos de eventos por cada mensaje?
Sí. Eventos de entrega, rebote y queja están disponibles para flujos operativos y de producto.
¿Sirve para tráfico de alto volumen?
Sí. El mismo modelo de API se usa desde fases de bajo volumen hasta envío sostenido de alto volumen.
¿Necesitamos SPF, DKIM y DMARC para el envío por API?
Autenticar su dominio de envío es muy recomendable. Mejora cómo los proveedores de buzón evalúan su correo y es una expectativa base en producción.
¿Cómo funcionan las claves API y los permisos?
Puede emitir claves por entorno o servicio y restringir lo que cada clave puede hacer, para aislar staging, CI y producción.
¿Qué pasa si nuestra integración envía solicitudes inválidas o duplicadas?
La API devuelve errores de validación claros. Para reintentos, use identificadores estables en su aplicación para no duplicar el mismo correo visible para el usuario.
¿Podemos correlacionar llamadas API con la entrega posterior?
Sí. Identificadores de mensaje y líneas de tiempo de eventos conectan un envío API con resultados aceptado, entregado, rebotado o diferido.
¿La API de correo encaja en restablecimientos de contraseña y códigos OTP?
Sí. Son casos transaccionales clásicos: expectativas de baja latencia, alta visibilidad y acoplamiento con sus sistemas de autenticación o riesgo.
¿Debemos usar solo HTTPS para el tráfico de la API?
Sí. TLS protege credenciales y metadatos en tránsito. Trate los puntos finales de la API como cualquier superficie de producción con secretos.
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).
Productos relacionados
Protege email crítico en cada tenant.
Mueve tu stream más crítico a Sendarix esta semana. Deja todo lo demás exactamente donde está.
