Cómo funciona

Del payload al acuse de entrega en menos de 500ms

Capa por capa, sin caja negra. Componentes conocidos, decisiones de diseño que podemos explicar y el mismo recorrido para WhatsApp, RCS, SMS, correo electrónico, push e Instagram Messages.

Arquitectura

Pipeline non-blocking de extremo a extremo

La misma cola, el mismo worker y el mismo registro para los seis canales. Cada capa está pensada para que su petición no espere: acuse de entrega, reintento con backoff, rate limiting distribuido y trazabilidad por mensaje.

Su backend

App / CRM / ERP

API Gateway

REST · Webhooks · SDKs

Cola priorizada

Por organización y tipo

Workers paralelos

Pipeline asíncrono

Conectores de canal

Meta · SMPP · SMTP · Push

Webhooks

Callbacks · Estado

Rendimiento

Pipeline 100% asíncrono: la API escribe y la cola entrega. Colas priorizadas por organización y por tipo de mensaje, para que una campaña no retrase un OTP.

Resiliencia

Reintento con backoff exponencial y reconciliación periódica con el conector de cada canal.

Observabilidad

Cada mensaje trazable de extremo a extremo: log, métrica, tracing y alerta.

Recorrido de un mensaje

8 pasos de su backend al canal

Paso 01

Ingesta

POST /v1/messages llega al borde

El gateway valida el esquema y la firma del token, deduplica por idempotency_key y encamina a la cola que toca. 100% non-blocking: devolvemos 202 en menos de 40ms con un message_id ya persistido.

API GatewayJWT + ámbitosIdempotencia nativa de 24hValidación OpenAPI 3.1

Paso 02

Encolado

Cola priorizada por organización y tipo

El mensaje entra en colas separadas por prioridad (critical, high, default, low) y por organización. Así una campaña de marketing pesada nunca retrasa un OTP. El rate limiting es distribuido, por plantilla y por remitente.

Cola priorizada por organizaciónCuatro niveles (critical/high/default/low)Rate limiting distribuido

Paso 03

Procesamiento

Workers paralelos consumiendo en bucle

Cada worker toma un lote, hidrata las variables de la plantilla, aplica las reglas de segmentación y llama al conector del canal. El pool escala solo, con backpressure: no ahogamos al proveedor de destino ni en pico.

Workers paralelos con escalado automáticoBackpressure adaptativoPool de conexiones por conector

Paso 04

Conector del canal

Meta Cloud API, gateway SMPP, SMTP o push

El conector devuelve un identificador y luego notifica el estado (queued → sent → delivered → read). Si hay error, lo clasificamos en recuperable o terminal y aplicamos la política que corresponde a cada canal.

Meta Graph API v19+Timeout agresivo (2s)Circuit breaker por remitente

Paso 05

Reintento y reconciliación

El fallo no cierra el caso, lo abre

El error recuperable pasa a un buffer de reintentos con backoff exponencial (2s → 4s → 8s → 16s → 32s → 1min → 5min → 30min). Tras 7 intentos, el mensaje entra en reconciliación continua con el proveedor cada 6h durante 7 días.

Buffer de reintentosBackoff exponencialReconciliación automática

Paso 06

Persistencia

El núcleo de datos es la fuente de verdad

Cada transición de estado se guarda con marca de tiempo, metadatos del proveedor, coste facturable e identificador de traza. Los índices compuestos por organización, estado y fecha mantienen la consulta en milisegundos con el histórico completo.

Aislamiento por organizaciónTTL automático en los logsÍndices compuestos

Paso 07

Webhooks salientes

Su backend recibe cada evento

Cada transición genera un webhook firmado con HMAC SHA-256 hacia su endpoint. Reenvío automático con backoff hasta 24h, orden garantizado por message_id y reproducción manual desde el panel para los últimos 30 días.

HMAC SHA-256Worker de reenvíoReproducción desde el panel

Paso 08

Observabilidad

Cada mensaje trazable de extremo a extremo

Todo el pipeline emite logs estructurados, métricas en formato Prometheus y trazas OpenTelemetry. Un único trace_id le lleva de la ingesta al webhook saliente. Panel de métricas por organización.

OpenTelemetryPrometheus + GrafanaLogs estructurados en JSON
Pilares

Tres decisiones de arquitectura que sostienen el resto

Multi-tenant de origen

Cada organización tiene sus propias colas, sus propios límites y su almacenamiento aislado. El acceso al dato de otra organización responde como inexistente, no como prohibido.

Seguridad por capas

Tokens con ámbito, rotación sin parada, dato personal cifrado en reposo (AES-256) y en tránsito (TLS 1.3), y audit log que no se reescribe.

Observabilidad completa

Un único trace_id le lleva de la llamada a la API al webhook saliente. Panel de métricas por organización. Nada de secretos sobre lo que pasa dentro de la plataforma.

Compromisos operativos

Lo que CCX le pone por escrito

Más allá del SLA, la lista de compromisos que entran en el contrato Enterprise y que funcionan por defecto en el resto de planes.

  • Idempotencia garantizada durante 7 días en todos los endpoints
  • Ningún mensaje enviado dos veces por un fallo interno nuestro
  • Buffer de hasta 7 reintentos y 7 días de reconciliación automática
  • Webhooks con reenvío automático de 24h y reproducción manual
  • SLA público con crédito en factura si lo incumplimos
  • Página de estado en tiempo real y postmortem público en menos de 48h
  • GDPR y LOPDGDD, con DPA y lista de subencargados [verificar]
  • Exportación completa de sus datos cuando quiera (CSV, JSONL, Parquet)

¿Leíste hasta aquí? Estás listo para probar.

Activa un sandbox en 2 minutos y envía tu primera plantilla aprobada. Sin tarjeta, sin lock-in.