Ya integré WhatsApp con Pipedrive y el equipo reporta que

Respuesta

Cuando WhatsApp y Pipedrive muestran mensajes ausentes, con retraso o duplicados, casi nunca es un solo problema: suele ser una mezcla de mapeo de identidad, reintentos de webhooks y visibilidad en Pipedrive. La forma más rápida de arreglarlo es acotar el síntoma con evidencia, mapear el flujo real y hacer un triage de 15 minutos con verificaciones de alto impacto. Si lo abordas en ese orden, normalmente encuentras una causa raíz clara en uno o dos ciclos. Piensa en ello como buscar un calcetín perdido: primero confirmas si se quedó en la lavadora, en el cesto o debajo de la cama, no compras calcetines nuevos a ciegas.

A partir de aquí te dejo un checklist práctico, siguiendo el flujo típico de integración y los puntos donde más se rompe, alineado con las guías de troubleshooting de Pipedrive para WhatsApp vía Twilio y para el Messaging Inbox, además de problemas frecuentes que aparecen

Definir el síntoma y el alcance antes de tocar config

El error común aquí es tocar credenciales, automatizaciones y apps “a ver si se arregla”, y con eso borrar el rastro. En su lugar, primero define exactamente qué está fallando y para quién.

Empieza con estas preguntas de diagnóstico, en lenguaje de negocio pero con datos verificables.

Quién lo ve: ¿todos los usuarios o solo un equipo? ¿solo el propietario del trato o cualquiera?

Qué número: ¿un solo número de WhatsApp Business o varios? ¿cambia según país?

Qué conversaciones: ¿solo clientes nuevos, solo clientes existentes, o ambos?

Cuándo: ¿horas pico, fines de semana, o después de cambios recientes?

Qué tipo de mensaje: texto, imagen, audio, documento, plantilla, respuesta a mensaje, o mensajes muy seguidos.

Y documenta tres ejemplos completos. Cada ejemplo debería tener:

Hora local y UTC del envío o recepción.
Captura del mensaje en WhatsApp o en el panel del proveedor.
Enlace interno o referencia del contacto y trato en Pipedrive.
Si existe, identificador del mensaje o del evento en el proveedor.

Tip práctico 1: crea una mini tabla de síntomas con métricas observables. Por ejemplo, “no aparece” se mide como diferencia entre conteo de mensajes en proveedor versus conteo en Pipedrive, “retraso” se mide como latencia por tramo, y “duplicado” como número de apariciones del mismo evento o contenido.

Mapear el flujo real de la integración donde puede fallar

En la mayoría de integraciones, el flujo real se parece a esto.

WhatsApp Business Platform entrega el evento al proveedor. Puede ser Twilio u otro BSP.

El proveedor llama a tu webhook o al conector, o bien una app intermedia procesa el evento.

Tu integración crea o actualiza el registro en Pipedrive. Puede entrar en el Messaging Inbox o registrarse como actividad o nota, según el método.

Finalmente el usuario lo ve, o no lo ve, en la interfaz por filtros, permisos o asignación.

Los puntos típicos de fallo son predecibles.

Webhooks no entregados o entregados tarde por timeouts, reintentos o caídas.

Reintentos que crean duplicados cuando no hay control idempotente, o cuando se procesa el mismo evento dos veces.

Mapeo de contacto por teléfono incorrecto que manda el mensaje a otro contacto, o crea un duplicado.

Permisos y visibilidad que hacen que “sí llegó” pero no aparece para quien lo busca.

Artefactos que conviene recolectar por cada mensaje, para poder seguir la pista de punta a punta.

Identificador del mensaje en el proveedor.

Identificador de conversación si existe.

Identificador del evento del webhook.

Timestamp de recepción en proveedor, timestamp de entrega del webhook, timestamp de escritura en Pipedrive.

Si usas una app propia o intermedia, agrega un requestId interno para correlación.

Si estás usando una app de mensajería construida como extensión, es útil conocer cómo Pipedrive espera que se publiquen mensajes en su marco de integración de mensajería, porque eso define qué campos permiten correlación y cómo aparece en UI. Referencia: tutorial de Pipedrive para construir una Messaging App Extension. [1]

Triage rápido 15 minutos: 8 verificaciones de alto impacto

Si tienes poco tiempo, estas ocho verificaciones suelen encontrar el 80 por ciento de las causas.

Estado del proveedor y del número de WhatsApp Qué buscar: alertas, degradación, quality rating bajo, bloqueos, limitaciones. Cómo confirmar: en el panel del proveedor revisa historial de estados, errores y webhooks. En integraciones con Twilio, Pipedrive recomienda revisar que el setup y el estado estén correctos antes de buscar en el CRM. [2]
Webhook activo y respondiendo rápido Qué buscar: errores 4xx o 5xx, timeouts, reintentos. Cómo confirmar: revisa logs del endpoint y verifica que responde 200 rápidamente, idealmente en menos de uno o dos segundos y que el procesamiento pesado ocurre después.
Doble integración escuchando el mismo número Qué buscar: dos conectores instalados, dos endpoints configurados, o un “puente” anterior que quedó vivo. Cómo confirmar: lista apps instaladas en Pipedrive, y revisa en el proveedor cuántas URLs de webhook están recibiendo eventos.
Cambios recientes Qué buscar: rotación de tokens, cambios de firewall, cambios de DNS, cambios en automatizaciones. Cómo confirmar: compara la fecha del primer incidente con el registro de cambios interno.
Permisos de usuario y visibilidad en Pipedrive Qué buscar: usuarios sin acceso a contactos, tratos o inbox, o reglas por equipos. Cómo confirmar: entra con un usuario admin y con un usuario afectado y busca el mismo mensaje.
Filtros del inbox y estados archivados Qué buscar: conversaciones archivadas, filtros por canal, asignación a otro usuario. Cómo confirmar: en el Messaging Inbox prueba cambiar filtros y ver si el mensaje aparece. Pipedrive tiene troubleshooting específico del Messaging Inbox que suele apuntar a visibilidad y configuración. [3]
Formato del teléfono y mapeo E.164 Qué buscar: números sin código de país, con ceros locales, extensiones, o duplicados. Cómo confirmar: revisa cómo está guardado el teléfono en Pipedrive y cómo llega desde el proveedor. Si no coincide, la conversación puede ir a otro contacto.
Ratios de duplicación y latencia por tramo Qué buscar: un mismo mensaje procesado dos veces, o latencia concentrada en un tramo. Cómo confirmar: toma los tres ejemplos documentados y calcula tiempos entre proveedor, webhook y Pipedrive.

Tip práctico 2: crea un “mensaje de prueba” estándar que todos usen para rastrear. Por ejemplo “TEST 1532” enviado desde un teléfono externo. Así evitas confundir pruebas y reduces discusiones tipo “yo juro que era otro chat”.

Mensajes entrantes que no aparecen en Pipedrive

Cuando un mensaje entrante no aparece, hay cuatro capas que revisar en orden.

Capa proveedor: el mensaje realmente entró. Si el panel del proveedor no lo muestra como recibido, el problema no es Pipedrive. Puede ser opt in, calidad del número, limitación o incidentes.

Capa webhook: el evento salió del proveedor y llegó a tu integración. Si el proveedor lo marca como enviado pero tu endpoint no lo registra, suele ser URL mal configurada, TLS, firewall, o un cambio de IP. En Twilio y setups similares, los reintentos aparecen cuando el endpoint no confirma correctamente.

Capa app o middleware: el evento llegó pero falló el procesamiento. Aquí aparecen errores por parseo, adjuntos, límites, o un fallo al escribir en Pipedrive.

Capa Pipedrive: el mensaje se creó, pero no donde lo estás buscando. Esto es muy común. El mensaje puede estar asociado a otro contacto por un match de teléfono distinto, o estar en un inbox con filtros, o asignado a otra persona. También puede existir como actividad o nota si la integración lo registra de esa manera.

Acciones correctivas que funcionan bien.

Confirma si el mensaje aparece bajo otro contacto. Busca por el número exacto en Pipedrive y revisa duplicados de persona.

Revisa si la integración crea leads en vez de tratos, o si manda conversaciones al Inbox pero el equipo mira solo el timeline del trato.

Si faltan adjuntos específicamente, prueba con texto simple y luego con archivo. Los archivos suelen añadir pasos de descarga y escaneo, y es donde aparecen timeouts.

Si estás usando la integración de WhatsApp vía Twilio, Pipedrive sugiere revisar el flujo de instalación y los puntos de configuración que suelen cortar el ingreso, y esa guía vale como checklist de “capas”. [2]

Retrasos: cómo medir latencia y localizar el cuello de botella

Si el equipo dice “llega tarde”, lo primero es convertirlo en números. La latencia total es la suma de cuatro tramos.

T1 WhatsApp a proveedor: desde que el cliente envía hasta que el proveedor lo marca recibido.

T2 proveedor a webhook: desde recibido hasta que el proveedor intenta entregar al endpoint.

T3 procesamiento a Pipedrive: desde que tu sistema recibe hasta que logra escribir en Pipedrive.

T4 visibilidad en UI: desde que Pipedrive lo guarda hasta que el usuario lo ve, que puede verse afectado por caché, filtros y permisos.

Cómo medir sin volverte loco.

Para cada uno de tus tres ejemplos, extrae timestamps del proveedor, del log de tu webhook o middleware y del registro en Pipedrive. Con eso puedes decir “el retraso está antes o después del webhook”.

Causas típicas por tramo.

Si T1 es alto, el problema suele ser red del usuario, incidentes del proveedor o calidad del número.

Si T2 es alto, revisa colas del proveedor y reintentos. Un endpoint lento empuja al proveedor a reintentar, lo cual aumenta retraso y también puede crear duplicados.

Si T3 es alto, revisa rate limiting de Pipedrive, picos de tráfico, procesamiento de adjuntos, y automatizaciones que se disparan y añaden carga.

Si T4 es alto, el problema suele ser filtros, asignación y permisos, más que “el mensaje no llegó”. La guía de troubleshooting del Messaging Inbox suele ser relevante aquí. [3]

Una heurística útil: si los retrasos ocurren en horas pico y se normalizan de noche, casi siempre es cola o limitación, no un bug misterioso.

Duplicados: patrones, causas y deduplicación segura

Los duplicados tienen patrones repetidos. Identificar el patrón ahorra días.

Patrón A: reintentos del webhook. El proveedor reenvía el mismo evento cuando no recibe confirmación 200 a tiempo. Si tu integración no es idempotente, lo crea dos veces.

Patrón B: doble integración. Dos apps o dos endpoints están escuchando el mismo número. Resultado: doble escritura en Pipedrive.

Patrón C: “eco” de mensajes salientes. Algunos setups generan un evento saliente y también uno entrante reflejado, y ambos se registran como si fueran distintos.

Patrón D: dos canales activos. Por ejemplo, un setup antiguo más uno nuevo, o un canal de inbox y otro de actividades.

Deduplicación segura, sin perder mensajes.

La idea es simple: si el proveedor te da un identificador estable del mensaje o del evento, tu sistema debe tratarlo como clave única. Si ya se procesó, se ignora el duplicado.

Si no tienes app propia y dependes de un conector, tu mejor palanca es eliminar la causa de doble ingesta, o asegurar que el webhook confirma rápido.

Prueba controlada.

Envía un solo mensaje de prueba y cuenta cuántos eventos llegan al webhook. Si llegan dos eventos idénticos, el problema está antes de Pipedrive. Si llega uno y en Pipedrive hay dos, el problema está en el procesamiento o en dos vías de escritura dentro del CRM.

Problemas de mapeo: contactos, números, formatos y conversaciones

Una parte grande de “no aparece” en realidad es “aparece en otro lado”. El culpable suele ser el mapeo de identidad.

Señales claras.

El mensaje existe en Pipedrive, pero bajo otra persona.

Aparecen personas duplicadas con el mismo nombre pero teléfonos distintos.

Después de un merge de contactos, las conversaciones quedan asociadas al registro antiguo.

Qué revisar.

Normalización E.164: guarda teléfonos con código de país y sin caracteres locales ambiguos. Si el proveedor entrega +34XXXXXXXXX y en Pipedrive está 6XXXXXXXX, el match puede fallar.

Campo correcto: define cuál es el “teléfono principal” para WhatsApp. Si hay varios teléfonos, decide regla, por ejemplo usar móvil como primario.

Duplicados de contactos: si hay dos personas con el mismo número en distintos formatos, la conversación puede quedar en cualquiera.

Reglas de creación automática: algunas integraciones crean una persona nueva cuando no encuentran match exacto. Eso es útil, pero si el match es frágil, se vuelve una máquina de duplicados.

Configuración y permisos en Pipedrive que ocultan o redirigen mensajes

Aquí es donde ejecutivos suelen decir “el sistema falla”, cuando en realidad el sistema funciona pero con reglas distintas a las que el equipo cree.

Revisiones que más esconden mensajes.

Visibilidad por equipos y propiedad: si el mensaje se asocia a un trato cuyo propietario es otro equipo, puede no verse.

Filtros del inbox: conversaciones archivadas, no asignadas, o vistas por canal.

Automatizaciones: reglas que cambian propietario, mueven el trato o convierten lead a trato pueden hacer que el mensaje “desaparezca” del lugar habitual.

Usuarios de integración: si el usuario técnico que crea actividades no tiene permisos correctos, puede fallar la creación o asociarse de forma incompleta.

Cómo confirmarlo rápido.

Haz una prueba con un usuario admin viendo el mismo contacto. Si el admin ve el mensaje y el comercial no, no es problema de WhatsApp, es visibilidad. La guía de troubleshooting del Messaging Inbox de Pipedrive es un buen punto de referencia para estas discrepancias. [3]

Proveedor y WhatsApp Business Platform: estados de entrega, ventanas y plantillas

No todo es “mensajería libre”. WhatsApp tiene reglas operativas que influyen en lo que tu equipo interpreta como retraso o fallo.

Estados de entrega. Un mensaje puede estar enviado desde Pipedrive, pero quedarse en estado de entregando, fallido o rechazado en el proveedor. Si no monitoreas esos estados, parece magia negra.

Ventana de atención. Fuera de la ventana de conversación, muchos envíos requieren plantillas aprobadas. Si el equipo intenta responder horas después con texto libre y falla, se confunde con “Pipedrive no envió”.

Plantillas. Rechazos de plantillas o cambios no aprobados generan fallos que no se arreglan cambiando nada en Pipedrive. Hay que verlo en el proveedor.

Opt in y cumplimiento. Mensajes a usuarios sin opt in pueden fallar o degradar el número, lo cual aumenta incidencias.

Si usas Twilio con Pipedrive, la documentación de troubleshooting te orienta sobre dónde ver problemas típicos de configuración y entrega en esa ruta específica. [2]

Instrumentación mínima: logs, correlación y alertas

Si quieres que esto deje de ser reactivo, necesitas una instrumentación mínima que no sea un proyecto eterno.

Objetivo: un trace por mensaje. Para cada mensaje, guarda una línea de log estructurado con: identificador del mensaje del proveedor, identificador del evento del webhook, dirección entrante o saliente, teléfono normalizado, identificador del contacto en Pipedrive, y los cuatro timestamps T1 a T4.

Alertas simples, alto valor.

Alerta por gap: si el proveedor recibió N mensajes en 10 minutos y Pipedrive solo muestra N menos X, dispara revisión.

Alerta por duplicados: si el mismo identificador aparece más de una vez, marca evento.

Alerta por latencia: si T2 o T3 supera un umbral, investiga colas o rate limiting.

Si tienes integración propia, revisa también cambios de APIs. Pipedrive ha publicado breaking changes como la deprecación de Channels API, que puede afectar integraciones antiguas o supuestos de canalización. [4]

A continuación tienes una tabla de controles prácticos que conviene revisar en cualquier integración WhatsApp a CRM.

Set: Credenciales de API suele explicar caídas súbitas tras rotación de tokens. Set: Configuración de Webhooks es la causa número uno de “no aparecen” cuando hubo cambios de red. Set: Mapeo de contactos explica el clásico “sí está, pero en otro contacto”. Set: Permisos de usuario explica el clásico “el admin lo ve, yo no”. Set: Reglas de automatización explica duplicados o desvíos que solo ocurren en ciertos tratos.

Cierre con prioridad clara.

Lo primero que haría mañana por la mañana es escoger tres ejemplos, medir T1 a T4 y verificar si hay doble ingesta de eventos. No optimices nada más hasta saber si el problema está en proveedor, webhook, procesamiento o visibilidad en Pipedrive. Una vez tengas esa respuesta, el arreglo suele ser sorprendentemente mundano: normalizar teléfonos, corregir webhooks, quitar una integración duplicada, o ajustar permisos y filtros del inbox.

Control	Dónde vive	Qué configurar	Qué se rompe si está mal
Set: Credenciales de API	Proveedor de WhatsApp y Pipedrive (integración)	Tokens de acceso, claves API, IDs de cuenta	Fallo de autenticación, integración inoperativa
Set: Configuración de Webhooks	Panel del proveedor de WhatsApp	URL de webhook apuntando a tu aplicación/Pipedrive, eventos suscritos	Mensajes entrantes no llegan a Pipedrive
Set: Mapeo de contactos	Configuración de la integración (Pipedrive o app intermedia)	Campo de teléfono de WhatsApp a campo de teléfono de Pipedrive	Conversaciones no se asocian a contactos existentes o crean duplicados
Set: Permisos de usuario	Pipedrive (ajustes de usuario y roles)	Acceso a actividades, contactos, tratos para usuarios de la integración	Usuarios no pueden ver o interactuar con los mensajes de WhatsApp en Pipedrive
Set: Reglas de automatización	Pipedrive (Automatizaciones, Flujos de trabajo)	Condiciones y acciones para mensajes de WhatsApp (ej. crear trato)	Flujos de trabajo no se disparan o se disparan incorrectamente con mensajes de WhatsApp
Set: Estado del proveedor de WhatsApp	Panel del proveedor (Twilio, 360dialog, etc.)	Verificar estado de servicio y alertas	Mensajes no llegan a Pipedrive o no se envían desde Pipedrive

Fuentes

Última actualización: 2026-07-29 | Calypso

Fuentes

developers.pipedrive.com — developers.pipedrive.com
support.pipedrive.com — support.pipedrive.com
support.pipedrive.com — support.pipedrive.com
developers.pipedrive.com — developers.pipedrive.com

Ya integré WhatsApp con Pipedrive y el equipo reporta que algunos mensajes no aparecen, llegan con retraso o salen duplicados. ¿Qué checklist debo seguir para (

Respuesta

Fuentes

Fuentes

Etiquetas