Límites de velocidad de la API de WhatsApp: qué ocurre cuando envías demasiados mensajes

Diagrama de rate limits de WhatsApp API — tres sistemas de límite: throughput por segundo, tier de mensajería diario, cap de frecuencia por destinatario — con feedback loop de calidad

En este artículo: Los tres sistemas de rate limit · Tabla de tiers de mensajería · Reglas de progresión de tier · Calidad (GREEN/YELLOW/RED) · Cap de frecuencia por destinatario · Códigos de error exactos y respuestas · Qué nunca reintentar · Comportamiento de pausa de cuenta · Código de retry para producción · Estrategia de warm-up de número · FAQ

Los tres sistemas de rate limit — y por qué son diferentes

Lo más importante que entender sobre los rate limits de WhatsApp: hay tres sistemas completamente separados, cada uno mantenido independientemente por la infraestructura de Meta. Llegar a uno no significa que has llegado a los otros. Manejarlos incorrectamente — especialmente reintentar mensajes que nunca deberían reintentarse — empeora activamente tu calidad y acelera el problema.

Throughput por segundo

80 mensajes/segundo por número de teléfono. Límite de infraestructura del API. Devuelve HTTP 429 inmediatamente. Reintenta con exponential backoff.

HTTP 429

Tier de mensajería diario

1K / 10K / 100K / Ilimitado contactos únicos iniciados por negocio cada 24h. Se reinicia a medianoche UTC. NO reintentes el mismo día.

Error 131048

Cap de frecuencia por destinatario

Meta bloquea silenciosamente mensajes marketing a destinatarios que han recibido demasiados de cualquier negocio en las últimas 24–48h. Nunca reintentes.

Error 131049

Rate limit 1: throughput del API por segundo

La Cloud API soporta 80 mensajes por segundo por número de teléfono por defecto. Es un límite puro de infraestructura del API — aplicado a nivel de milisegundo. Excederlo devuelve HTTP 429 inmediatamente con un error de rate limit estándar. Este límite es escalable: contacta a Meta para aumentarlo a 1.000 mensajes por segundo para senders de alto volumen.

La respuesta de error cuando alcanzas este límite:

HTTP 429 Response
per-second-limit.json
HTTP/1.1 429 Too Many Requests
Retry-After: 1
Content-Type: application/json

{
  "error": {
    "message": "(#613) Calls to this api have exceeded the rate limit.",
    "type":    "OAuthException",
    "code":    613,
    "fbtrace_id": "AbCdEfGh..."
  }
}

// Reintentar: SÍ — usa exponential backoff empezando en 1 segundo
// El header Retry-After es orientativo — respétalo pero añade también jitter

Prevenir es mejor que recuperarse. A 80 msg/s, enviar 10.000 mensajes lleva 125 segundos. Para operaciones masivas, añade 15–20ms de delay entre envíos para mantenerte cómodamente por debajo de 50–60 msg/s — seguro bajo el límite manteniendo una tasa de éxito de entrega del 99%+.

Rate limit 2: límites del tier de mensajería diario

Este es el límite que la mayoría de la gente quiere decir cuando dice "rate limits de WhatsApp". El tier de mensajería controla a cuántos clientes únicos puede enviar tu número de teléfono mensajes iniciados por negocio en una ventana rolling de 24 horas. El tier es por número de teléfono, no por cuenta.

Los mensajes de sesión no están limitados por tier. El tier de mensajería diario solo cuenta los mensajes iniciados por el negocio — mensajes de plantilla enviados para iniciar nuevas conversaciones o a clientes fuera de la ventana de servicio de 24 horas. Cuando un cliente te envía un mensaje primero, todas las respuestas dentro de la ventana de servicio resultante de 24 horas son mensajes de sesión — NO cuentan hacia tu tier diario. Puedes enviar mensajes de sesión ilimitados en cualquier tier.

Tier	Contactos únicos / 24h	Estado inicial	Condición de upgrade	Condición de downgrade
Tier 1	1.000 contactos únicos	Todos los nuevos números	7 días de uso consistente al 80%+ de capacidad, calidad GREEN/YELLOW	La calidad baja a RED
Tier 2	10.000 contactos únicos	Auto-upgrade	7 días al 80%+ de 10K/día, calidad GREEN/YELLOW	Calidad RED → baja a Tier 1
Tier 3	100.000 contactos únicos	Auto-upgrade	7 días al 80%+ de 100K/día, calidad GREEN/YELLOW	Calidad RED → baja a Tier 2
Tier 4	Ilimitado	Auto-upgrade	Conseguido tras la progresión del Tier 3	Calidad RED → baja a Tier 3

La respuesta de error cuando excedes tu tier diario:

HTTP 200 con error en body (status: failed)
error-131048.json
{
  "messaging_product": "whatsapp",
  "contacts": [{ "input": "+15550001234", "wa_id": "15550001234" }],
  "messages": [{ "id": "wamid.HBgL..." }]
}

// El envío inicial devuelve 200. El fallo llega luego como evento de status webhook:
{
  "statuses": [{
    "id":     "wamid.HBgL...",
    "status": "failed",
    "errors": [{
      "code":    131048,
      "title":   "Message failed to send because too many messages were sent from the sender phone number.",
      "details": "Messages to this phone number are being sent too quickly."
    }]
  }]
}

// CRÍTICO: NO reintentes con 131048. Espera al reset de medianoche UTC.
// Reintentar desperdicia llamadas API y no evita el límite de tier.

Progresión de tier: cómo ir de 1K a Ilimitado

La promoción de tier de Meta es automática — no puedes solicitarla directamente. Sucede basándose en tres señales medidas sobre una ventana rolling de 7 días:

Umbral de volumen: Debes alcanzar consistentemente el 80%+ del límite diario de tu tier actual. Un número en Tier 1 que solo envía 200 mensajes/día nunca sube — incluso con calidad perfecta.
Calidad: Debe ser GREEN o YELLOW. Una calidad RED bloquea la promoción por completo y dispara un downgrade inmediato.
Tiempo: Meta evalúa tras 7 días consecutivos cumpliendo ambos criterios. La promoción no es instantánea.

Tier 1

1K / día

Tier 2

10K / día

Tier 3

100K / día

Tier 4

Ilimitado

El downgrade es inmediato, la promoción no: Una bajada de calidad a RED te baja inmediatamente un tier — te despiertas al día siguiente con un límite menor. Recuperarse requiere 7 días de operación limpia en el nuevo tier inferior. Esta asimetría significa que una sola campaña de broadcast mala puede retrasar la progresión de tu tier en semanas. Protege tu calidad tan agresivamente como proteges la reputación del sender.

El feedback loop del quality rating

El quality rating (GREEN / YELLOW / RED) es el número más importante en la salud de tu WhatsApp API. Lo calcula Meta sobre una ventana rolling de 7 días basándose en señales de los destinatarios de mensajes — específicamente: bloqueos, reportes de spam y feedback negativo relativos a tu volumen de envío.

GREEN

Saludable — elegible para upgrade de tier

Baja tasa de bloqueos y reportes de spam respecto al volumen de envío. Los destinatarios interactúan positivamente — responden, continúan las conversaciones. Elegible para upgrade automático tras 7 días al 80%+ de capacidad. Este es el estado objetivo para cualquier sender en producción.

YELLOW

Aviso — upgrade de tier pausado

Tasa moderada de bloqueos o reportes de spam. Aún puedes enviar al límite de tu tier actual — sin downgrade inmediato. Pero el upgrade está pausado. Meta observa durante 7 días: si la calidad mejora a GREEN, te quedas en el tier actual. Si se degrada a RED, downgrade inmediato.

RED

Crítico — downgrade inmediato

Alta tasa de bloqueos o reportes de spam. Inmediato: bajas un tier. RED sostenido durante 7+ días arriesga que el número sea flagueado o deshabilitado por completo. Este es el estado de fallo en cascada — una campaña mala crea calidad RED → downgrade → la siguiente campaña tiene menos capacidad → más presión para enviar al límite → más bloqueos.

El quality rating no se expone en la Cloud API directamente — debes consultarlo en Meta Business Manager (WhatsApp Manager → Phone Numbers → columna Quality Rating) o suscribirte al campo webhook phone_number_quality_update. Suscríbete a este campo y construye alertas para saber inmediatamente cuando tu calidad se degrada.

Rate limit 3: cap de frecuencia por destinatario (el que nadie explica)

Este es el rate limit que más confunde a los desarrolladores porque es totalmente separado del tier de tu cuenta, opera globalmente entre todos los negocios, y falla silenciosamente con un mensaje de error engañoso.

El frequency capping de Meta limita cuántos mensajes marketing puede recibir un usuario específico de WhatsApp de cualquier negocio en una ventana de tiempo definida (24–48 horas). Es Meta protegiendo a los usuarios de la sobrecarga de mensajes marketing en toda la plataforma — no solo tus mensajes. Si un usuario ha recibido mensajes de plantilla marketing de otros 5 negocios hoy, tu mensaje marketing perfectamente legítimo a ese usuario puede ser bloqueado silenciosamente.

El error que recibes:

Status webhook — error 131049
frequency-cap-error.json
{
  "statuses": [{
    "id":     "wamid.HBgL...",
    "status": "failed",
    "errors": [{
      "code":    131049,
      "title":   "This message was not delivered to maintain a healthy ecosystem.",
      "details": "Unhealthy system activity"
    }]
  }]
}

// Esto es frequency capping por destinatario — no es culpa de tu cuenta
// Afecta SOLO a plantillas MARKETING
// Las plantillas UTILITY y AUTHENTICATION NO tienen frequency cap por destinatario
// NO reintentes — el cap es a nivel de sistema, no por sender
// Loguea los contactos fallidos, no reintentes durante 48h

Hechos clave sobre el frequency capping por destinatario:

Solo plantillas marketing. Las plantillas utility (confirmaciones de pedido, actualizaciones de envío, recordatorios de cita) y las plantillas authentication (OTPs) NO están sujetas a frequency capping por destinatario. Si tu campaña "marketing" puede clasificarse legítimamente como utility, reclasifica la plantilla.
El cap es global, no por sender. No tienes visibilidad de cuántos mensajes marketing ha recibido el destinatario de otros negocios. No puedes predecir qué envíos serán capeados.
Tasa de fallo esperada del 10–40% en campañas marketing a usuarios muy activos de WhatsApp es normal. No es un problema de tu cuenta — es la plataforma protegiendo a los usuarios. Presupuéstalo.
Nunca reintentes fallos 131049. El destinatario estará capeado de frecuencia durante 24–48 horas. Reintentar desperdicia envíos, quema tu cuota diaria de tier y potencialmente daña tu calidad.

Referencia completa de códigos de error

HTTP 429

Límite de throughput por segundo excedido

Demasiadas llamadas API en muy poco tiempo. Devuelto inmediatamente con header Retry-After. Tu tasa de envío excedió 80 msg/s (o tu límite personalizado). Es un bloqueo a nivel de infraestructura — el mensaje nunca se encoló.

✓ Reintentar con exponential backoff + jitter

131048

Límite del tier de mensajería diario excedido

Tu número de teléfono ha alcanzado su límite de contactos únicos de 24h para el tier actual (1K, 10K o 100K). El envío parece tener éxito inicialmente (devuelve 200) pero falla asíncronamente — recibes este código en un evento de status webhook. El mensaje no fue entregado.

⏳ No reintentes hoy — programa tras el reset de medianoche UTC

131049

Frequency cap por destinatario — "Unhealthy system activity"

El destinatario específico ha recibido demasiados mensajes marketing de todos los negocios en las últimas 24–48 horas. Meta bloqueó la entrega de tu plantilla marketing para proteger a este usuario. Aplica solo a plantillas de categoría marketing. Las plantillas utility y authentication no están afectadas.

✗ Nunca reintentes — el destinatario está globalmente capeado durante 24–48h

131016

Servicio temporalmente no disponible

Error transitorio de infraestructura de Meta. No es un rate limit — un fallo del lado del servidor. El mensaje puede o no haber sido encolado antes del error. Seguro reintentar tras 30–60 segundos. Comprueba Meta Status para incidentes en curso.

✓ Reintenta tras 30–60s (máx. 3 intentos)

131031

Cuenta de negocio bloqueada

Tu WhatsApp Business Account ha sido bloqueada temporalmente por actividad sospechosa o violación de política. Todos los envíos fallan inmediatamente. Comprueba Meta Business Manager para los detalles de la violación. No intentes saltártelo — resuelve la violación directamente con soporte de Meta.

✗ No reintentar — resuelve la violación en Meta Business Manager

Qué nunca reintentar — la regla que salva tu quality rating

El error más dañino en el manejo de errores del WhatsApp API: reintentar errores 131048 y 131049. Ambos son fallos asíncronos — el API devolvió 200, pensaste que el mensaje fue enviado, luego recibes el error en un evento de status webhook. Muchos desarrolladores ven el fallo y reintentan inmediatamente. Esto está mal, y aquí está el porqué:

131048 (límite de tier): La ventana no se reinicia hasta medianoche UTC. Reintentar significa que quemas mensajes adicionales de tu cuota diaria, fallas de nuevo y quemas más cuota. También arriesgas enviar al mismo cliente un mensaje duplicado cuando la ventana se reinicie. Loguea el fallo con el tiempo de retry programado (medianoche UTC) y sigue adelante.
131049 (frequency cap): El destinatario está capeado a nivel de sistema, no por ti. Reintentar no hace nada salvo: (a) consumir tu cuota diaria de tier, (b) arriesgar generar una señal de "failed" de estado de entrega que podría afectar marginalmente tu calidad si se interpreta como intento de spam, (c) potencialmente molestar al destinatario cuando el cap se levante y reciba duplicados. Loguea y omite durante 48 horas.

El árbol de decisión de retry: HTTP 429 → reintenta con backoff. Error 131048 en status webhook → loguea, programa tras medianoche UTC. Error 131049 en status webhook → loguea, omite durante 48h. Error 131016 → reintenta una vez tras 30–60s. Error 131031 → detén todos los envíos, arregla la cuenta. Cualquier otro 5xx → reintenta hasta 3 veces con exponential backoff.

Pausa de cuenta vs restricción a nivel de número

Hay dos estados de cuenta diferentes que parecen "mi cuenta dejó de funcionar" pero tienen causas y soluciones distintas:

Restricción de número de teléfono — la mensajería del número de teléfono específico está limitada o pausada. Sucede cuando la calidad permanece RED durante 7+ días o cuando el número recibe una violación de política específica. Otros números en tu WABA siguen funcionando. Comprueba el estado del número en WhatsApp Manager → Phone Numbers. El campo status muestra "Connected", "Offline", "Flagged" o "Restricted".

Suspensión de WABA — toda la cuenta WhatsApp Business está suspendida. Todos los números bajo el WABA dejan de enviar y recibir. Sucede por violaciones de política graves o detección de fraude a nivel de cuenta. Recibes un evento webhook account_update con event: ACCOUNT_RESTRICTION o event: ACCOUNT_VIOLATION.

Para agencias: por esto una WABA por cliente es obligatorio. La suspensión de la WABA de un cliente tiene cero efecto en las WABAs de otros clientes.

Código de retry para producción: manejar todos los tipos de rate limit correctamente

Node.js — envío productivo consciente de rate limits
rateLimitAwareSend.js
const { sendWhatsApp }     = require('./whatsapp');
const { scheduleRetry }   = require('./scheduler');
const { logFailure }      = require('./logger');

// Códigos de error que NUNCA deben reintentarse inmediatamente
const NO_RETRY_CODES     = new Set([131049, 131031]);  // freq cap, bloqueo de cuenta
const RETRY_NEXT_DAY     = new Set([131048]);             // límite de tier
const RETRY_WITH_BACKOFF = new Set([131016]);             // error transitorio

async function sleep(ms) { return new Promise(r => setTimeout(r, ms)); }

// Maneja los 429 por segundo con exponential backoff
async function sendWithThroughputRetry(to, body, attempt = 0) {
  try {
    return await sendWhatsApp(to, body);
  } catch (err) {
    if (err.status !== 429 || attempt >= 5) throw err;

    // Exponential backoff con jitter para el límite de throughput por segundo
    const delay = Math.min(
      1000 * 2 ** attempt + Math.random() * 500,
      60000
    );
    console.warn(`429 — waiting ${Math.round(delay)}ms (attempt ${attempt + 1}/5)`);
    await sleep(delay);
    return sendWithThroughputRetry(to, body, attempt + 1);
  }
}

// Llamado desde tu handler de status webhook cuando un mensaje falla asíncronamente
async function handleFailedStatus(failedStatus) {
  const errorCode = failedStatus.errors?.[0]?.code;
  const recipient = failedStatus.recipient_id;
  const messageId = failedStatus.id;

  if (NO_RETRY_CODES.has(errorCode)) {
    // 131049: frequency cap — omitir 48h. 131031: bloqueo de cuenta — arreglar manualmente.
    await logFailure({ messageId, recipient, errorCode, action: 'no_retry' });
    return;
  }

  if (RETRY_NEXT_DAY.has(errorCode)) {
    // 131048: límite de tier diario — programar retry tras medianoche UTC
    const midnightUTC = new Date();
    midnightUTC.setUTCHours(0, 5, 0, 0); // 00:05 UTC del día siguiente — buffer de 5min
    midnightUTC.setUTCDate(midnightUTC.getUTCDate() + 1);

    await scheduleRetry({ messageId, recipient, retryAt: midnightUTC });
    await logFailure({ messageId, recipient, errorCode, action: 'scheduled_retry', retryAt: midnightUTC });
    return;
  }

  if (RETRY_WITH_BACKOFF.has(errorCode)) {
    // 131016: error transitorio — reintenta una vez tras 60s
    await scheduleRetry({ messageId, recipient, retryAt: new Date(Date.now() + 60000) });
    return;
  }

  // Código de error desconocido — logear y alertar para revisión manual
  await logFailure({ messageId, recipient, errorCode, action: 'manual_review' });
}

// Sender masivo con rate limiting integrado
async function bulkSendThrottled(contacts, message, delayMs = 20) {
  const results = { sent: 0, failed: [] };

  for (const contact of contacts) {
    try {
      await sendWithThroughputRetry(contact.phone, message);
      results.sent++;
    } catch (err) {
      results.failed.push({ ...contact, error: err.message });
    }
    await sleep(delayMs); // 20ms = ~50 msg/s — seguro bajo el límite de 80 msg/s
  }

  return results;
}

module.exports = { sendWithThroughputRetry, handleFailedStatus, bulkSendThrottled };

Warm-up de número: la forma correcta de construir hacia Tier 4

Un nuevo número de WhatsApp Business empieza en Tier 1 (1.000 contactos/día). Saltar inmediatamente a grandes campañas de broadcast es la forma más rápida de acumular bloqueos y reportes de spam, destruyendo tu calidad antes de haber construido cualquier señal de confianza. El enfoque correcto: warm-up gradualmente durante 2–4 semanas.

La estrategia de warm-up que maximiza la velocidad de progresión de tier mientras protege la calidad:

Semana 1: Envía solo a tus contactos de mayor engagement — clientes que te hayan respondido anteriormente, comprado recientemente o optado explícitamente a través de un proceso con fricción. Apunta a 500–800 contactos/día (80% de Tier 1). Monitorea la calidad a diario.
Semana 2–3: Si la calidad es GREEN, deberías auto-promocionarte a Tier 2. Aumenta a 7.000–8.000 contactos/día (80% de Tier 2). Continúa enviando solo a segmentos comprometidos. Suprime contactos no responsivos que no hayan interactuado en 90+ días.
Semana 4+: Continúa el patrón. Cada tier requiere 7 días al 80%+ de uso con calidad GREEN/YELLOW. Tiempo total de Tier 1 a Tier 4: mínimo 3–4 semanas de volumen consistente y de alta calidad.
Monitorea siempre las tasas de fallo 131049. Si ves fallos 131049 (frequency cap) excediendo el 20–25% de tus envíos, estás apuntando a demasiados usuarios de alta saturación. Mejora la calidad de tu lista o reduce la frecuencia antes de escalar más.

La excepción inbound: Los mensajes inbound (clientes contactándote primero) y las respuestas de sesión no cuentan hacia tu tier diario. Si tu operación de atención al cliente es principalmente inbound — clientes contactando, tu equipo respondiendo dentro de la ventana de 24h — puedes manejar miles de conversaciones diarias en Tier 1 sin preocupación de rate limit en absoluto. Los rate limits solo aplican a mensajes outbound iniciados por el negocio. Recibe tantos mensajes inbound como quieras en SocialHook por 50 $/mes plano — sin rate limit en el lado de recepción.

FAQ

Preguntas frecuentes

¿Cuáles son los tres tipos de rate limits del WhatsApp API?

(1) Throughput por segundo: 80 mensajes/segundo por número de teléfono — devuelve HTTP 429 inmediatamente. Reintenta con exponential backoff. (2) Tier de mensajería diario: limita contactos únicos iniciados por negocio cada 24 horas (1K/10K/100K/Ilimitado) — devuelve error 131048 asíncronamente vía webhook. NO reintentes hasta medianoche UTC. (3) Cap de frecuencia por destinatario: Meta bloquea silenciosamente mensajes marketing a usuarios que han recibido demasiados de todos los negocios en 24–48h — devuelve error 131049. Nunca reintentes.

¿Qué significa el error 131048 y debería reintentarlo?

El error 131048 significa "Message failed to send because too many messages were sent from the sender phone number" — has excedido tu límite del tier de mensajería diario. No reintentes el mismo día. La ventana del tier se reinicia a medianoche UTC. Programa un retry para las 00:05 UTC del día siguiente. Reintentar inmediatamente desperdicia tu cuota restante y no salta el límite.

¿Qué significa el error 131049 y por qué mi tasa de fallo es alta?

El error 131049 ("Unhealthy system activity") es el frequency cap por destinatario de Meta. El destinatario específico ha recibido demasiados mensajes marketing de todos los negocios en las últimas 24–48 horas. Una tasa de fallo 131049 del 10–40% en campañas marketing a usuarios activos de WhatsApp es completamente normal — no es un problema de tu cuenta. Esto solo afecta a plantillas de categoría marketing. Las plantillas utility y authentication no tienen frequency cap por destinatario. Nunca reintentes fallos 131049.

¿Cómo subo de tier de mensajería de WhatsApp?

Los upgrades de tier son automáticos — no puedes solicitarlos. Debes: (1) alcanzar consistentemente el 80%+ del límite diario de tu tier actual durante 7 días consecutivos, y (2) mantener calidad GREEN o YELLOW durante todo ese periodo. Si tu calidad es GREEN tras 7 días al 80%+ de capacidad, Meta te promociona automáticamente. YELLOW pausa la promoción. RED te baja inmediatamente un tier. Construye el tier centrándote primero en audiencias comprometidas para proteger la calidad.

¿Los mensajes de sesión (respuestas a conversaciones iniciadas por el cliente) cuentan hacia el tier diario?

No. El tier de mensajería diario solo cuenta mensajes iniciados por el negocio — mensajes de plantilla enviados para iniciar nuevas conversaciones o a clientes fuera de su ventana de servicio de 24 horas. Cuando un cliente te escribe primero y respondes dentro de la ventana resultante de 24 horas, esos son mensajes de sesión. No cuentan hacia tu límite de tier y no tienen tope diario en ningún nivel de tier.

¿Qué le pasa a mi quality rating cuando recibo bloqueos y reportes de spam?

Los bloqueos y reportes de spam reducen directamente tu quality rating sobre una ventana rolling de 7 días. Calidad YELLOW pausa la elegibilidad para upgrade. Calidad RED te baja inmediatamente un tier (p. ej., Tier 2 → Tier 1) y bloquea más upgrades hasta volver a GREEN. RED sostenido durante 7+ días puede resultar en que el número sea flagueado o deshabilitado temporalmente. Protege tu rating enviando solo a contactos opt-in que esperan tus mensajes, suprimiendo no comprometidos y clasificando mensajes como utility/authentication en lugar de marketing donde sea legítimo.

Sin límites en inbound

Los rate limits aplican al envío.
La recepción es ilimitada.

Cada mensaje inbound — independientemente del volumen — se entrega a tu endpoint webhook como JSON limpio. Sin límite por segundo, sin tier diario, sin frequency cap en recepción. Conecta tu número de WhatsApp a SocialHook y maneja tantas conversaciones inbound como generen tus clientes.

Conecta WhatsApp gratis → Lee la documentación

Sin tarjeta de crédito · 50 $/mes tras la prueba · Volumen inbound ilimitado

Límites de velocidad de la API de WhatsApp: qué ocurre cuando envías demasiados mensajes

Los tres sistemas de rate limit — y por qué son diferentes

Rate limit 1: throughput del API por segundo

Rate limit 2: límites del tier de mensajería diario

Progresión de tier: cómo ir de 1K a Ilimitado

El feedback loop del quality rating

Rate limit 3: cap de frecuencia por destinatario (el que nadie explica)

Referencia completa de códigos de error

Qué nunca reintentar — la regla que salva tu quality rating

Pausa de cuenta vs restricción a nivel de número

Código de retry para producción: manejar todos los tipos de rate limit correctamente

Warm-up de número: la forma correcta de construir hacia Tier 4

Preguntas frecuentes

Los rate limits aplican al envío.
La recepción es ilimitada.

¿Listo para construir? Empieza con SocialHook.

WhatsApp Business API en Brasil: Todo lo que los desarrolladores necesitan saber

Cómo manejar mensajes multimedia de WhatsApp en webhooks (imágenes, documentos, notas de voz)

WhatsApp Business API para agencias: gestión de múltiples números de clientes

Deja de gestionar las APIs de Meta.
Empieza a construir.

Límites de velocidad de la API de WhatsApp: qué ocurre cuando envías demasiados mensajes

Los tres sistemas de rate limit — y por qué son diferentes

Rate limit 1: throughput del API por segundo

Rate limit 2: límites del tier de mensajería diario

Progresión de tier: cómo ir de 1K a Ilimitado

El feedback loop del quality rating

Rate limit 3: cap de frecuencia por destinatario (el que nadie explica)

Referencia completa de códigos de error

Qué nunca reintentar — la regla que salva tu quality rating

Pausa de cuenta vs restricción a nivel de número

Código de retry para producción: manejar todos los tipos de rate limit correctamente

Warm-up de número: la forma correcta de construir hacia Tier 4

Preguntas frecuentes

También en SocialHook

Los rate limits aplican al envío.La recepción es ilimitada.

¿Listo para construir? Empieza con SocialHook.

WhatsApp Business API en Brasil: Todo lo que los desarrolladores necesitan saber

Cómo manejar mensajes multimedia de WhatsApp en webhooks (imágenes, documentos, notas de voz)

WhatsApp Business API para agencias: gestión de múltiples números de clientes

Deja de gestionar las APIs de Meta.Empieza a construir.

Los rate limits aplican al envío.
La recepción es ilimitada.

Deja de gestionar las APIs de Meta.
Empieza a construir.