Email API REST con SDKs en 8 lenguajes — para SaaS y plataformas donde el envío es parte del producto

SDKs oficiales mantenidos por nuestro equipo en Node.js (TypeScript completo), Python (3.9+), PHP (8.0+), Ruby (3.0+), Go (1.20+), Java (11+), C# (.NET 6+) y Elixir (1.14+). Todos publicados en sus repositorios de paquetes nativos (npm, PyPI, Packagist, RubyGems, Go modules, Maven Central, NuGet, Hex). Si trabaja en otro lenguaje, la API REST está documentada con OpenAPI 3.0 y puede generar el cliente con generadores estándar como openapi-generator.

En cada llamada a la API, el campo opcional 'category' (valores: transactional, promotional o un identificador custom) determina por qué pool de IPs sale el mensaje. En planes Growth y Pro hay dos pools de IPs separados por defecto — uno para tráfico transaccional crítico (confirmaciones, recuperación de contraseña), otro para tráfico promocional (newsletters, ofertas). La separación protege la reputación del pool transaccional ante un eventual problema en una campaña promocional. En Starter los pools se comparten dentro del cliente; la separación se activa al subir a Growth.

Los webhooks se entregan a su endpoint HTTPS para los eventos: delivery, bounce_hard, bounce_soft, complaint, opened, clicked, unsubscribed. Cada webhook lleva un HMAC-SHA256 firmado con su secret para verificación. Si su endpoint responde con cualquier código diferente de 2xx, reintentamos con backoff exponencial: 30 segundos, 2 minutos, 10 minutos, 1 hora, 4 horas, 12 horas. Tras 6 intentos fallidos, marcamos el evento como undelivered y queda disponible vía API para recuperación manual. El panel de cliente muestra la cola de reintentos en tiempo real.

Sí. Cada request a /v1/messages acepta el header 'Idempotency-Key' con un valor único definido por su aplicación (recomendamos UUID v4). Si la misma key llega dos veces en menos de 24 horas, devolvemos la respuesta original sin enviar el mensaje de nuevo. Esto resuelve el clásico problema de retry storms tras un timeout dudoso del cliente: puede reintentar la llamada con confianza sabiendo que no causará duplicados.

En Starter, 50 requests/segundo por API key con burst de hasta 200. En Growth, 200/segundo con burst de 500. En Pro, 500/segundo con burst de 1.000. Los límites se aplican por API key, así que aplicaciones con alta concurrencia pueden distribuir tráfico entre varias keys. Los headers HTTP estándar X-RateLimit-Limit, X-RateLimit-Remaining y X-RateLimit-Reset acompañan cada respuesta. Si necesita límites mayores para casos puntuales (lanzamiento de producto, notificación masiva sincronizada), lo conversamos previamente y ajustamos.

Tres opciones. Primera, modo sandbox: cada API key tiene una variante 'test' que acepta llamadas idénticas pero no envía realmente — útil para validar la integración sin gastar volumen. Segunda, dirección de prueba: cualquier mensaje enviado a sink@authorizehosting.com se procesa hasta el último paso pero se descarta antes de la entrega real, devolviendo todos los eventos como si fuera un envío exitoso. Tercera, entornos de staging completos con su propio set de credenciales y sus propias IPs dedicadas — disponibles en planes Pro a coste adicional.

En plan Pro hay SLA contractual del 99,95% de disponibilidad de la API y de procesamiento de mensajes. La medición es mensual sobre la suma de minutos de degradación. Si no cumplimos, aplicamos crédito en factura del mes siguiente: 10% si la disponibilidad cae al 99,5-99,95%, 25% si cae al 99-99,5%, 50% si cae por debajo del 99%. En Starter y Growth ofrecemos best-effort sin SLA contractual, pero la disponibilidad histórica viene siendo de 99,97% medida internamente.

Sí. Los webhooks pueden configurarse para envío directo a integraciones de Datadog Events, New Relic Insights, o ingest genérico vía endpoint HTTPS. Los logs JSON line-delimited son consumibles directamente por Elasticsearch, Splunk, Loki u otros sistemas de observabilidad. En plan Pro incluimos un dashboard de Grafana preconfigurado que el cliente puede exportar al suyo.