Una plataforma de seguimiento de enlaces registra lo que ha pasado con tus enlaces. Con un webhook, la plataforma avisa a tus otros sistemas en el momento en que ocurre, en lugar de esperar a que alguien mire un panel. Esa combinación es la que hace que un nuevo enlace de campaña aparezca en tu CRM en cuanto se crea, o que la apertura de un enlace secreto actualice un ticket.
Elegir una plataforma de seguimiento de enlaces con integraciones de webhooks exige mirar más allá de «tiene webhooks»: qué eventos envía, cómo los protege y qué no envía. Esta guía explica todo eso, cómo construir un receptor fiable y cuándo la API es mejor herramienta.
Para qué sirven los webhooks de una plataforma de enlaces
Hay tres usos que se repiten.
- Mantener los sistemas sincronizados. Un enlace creado en la plataforma aparece en la ficha de la campaña en tu CRM o en tu herramienta de proyectos, con su slug y su destino, sin que nadie lo copie.
- Lanzar flujos de trabajo. Un enlace secreto que se ha abierto marca una entrega como completada; uno que se ha destruido sin que el destinatario lo confirme abre un incidente.
- Alimentar un almacén de datos. Los eventos llegan a una cola y después a una tabla, donde se cruzan con el resto de tus datos.
Para lo que no sirven los webhooks es para contar. Un panel que suma uno por cada webhook se desviará del informe de la propia plataforma la primera vez que un envío se reintente o se retrase. Usa la API o una exportación para las cifras y los webhooks para las acciones.
Qué eventos buscar
Cada plataforma emite eventos distintos. Pide la lista, no la casilla marcada en la página de funciones.
| Familia de eventos | Eventos habituales | Útil para |
|---|---|---|
| Ciclo de vida del enlace | creado, actualizado, eliminado | Sincronizar con el CRM, registro de auditoría, detectar ediciones accidentales |
| Ciclo de vida del secreto | creado, visto, destruido | Confirmar entregas, abrir incidentes |
| Eventos de clic | por clic o agrupados | Automatización en tiempo real, con mucho volumen |
| Eventos de dominio | verificado, certificado emitido | Alertas de operaciones |
Los webhooks de LinkPilot cubren el ciclo de vida del enlace (link.created, link.updated, link.deleted) y el del secreto (secret.created, secret.viewed, secret.burned). Los datos de clics están disponibles a través de la API de estadísticas y de la exportación CSV, no como un webhook por clic. Para la mayoría de los equipos ese reparto es el correcto: los clics son datos de informe en gran volumen, mientras que los eventos de ciclo de vida son los que deben disparar algo.
Si tu flujo de trabajo de verdad necesita reaccionar a cada clic, confirma que la plataforma los agrupa o limita su ritmo. Si no, construirás un receptor que se cae la primera vez que una publicación se hace viral.
Qué más evaluar
- La firma. Cada envío debe llevar una firma calculada con un secreto que guardas tú, para que tu endpoint pueda rechazar falsificaciones. Una plataforma que envía webhooks sin firmar te pide que confíes en cualquier petición POST.
- Reintentos y orden. Averigua cuántas veces se reintenta un envío fallido y durante cuánto tiempo, y da por hecho que los eventos pueden llegar desordenados.
- ID de evento. Un identificador único por evento es lo que hace posible la idempotencia.
- Gestión de endpoints. Varios endpoints por espacio de trabajo, suscripciones por evento y un registro de envíos que puedas leer cuando algo falla.
- La API al lado. Webhooks para los disparadores, API para todo lo demás. Comprueba que la creación de enlaces, las estadísticas y las exportaciones estén disponibles mediante programación y que las claves se puedan limitar a ciertos permisos. La API de LinkPilot usa claves bearer
lp_live_y está en todos los planes. - El acceso del equipo. Quién puede añadir un endpoint de webhook importa, porque un endpoint recibe datos. Los roles deben permitir que un administrador gestione los endpoints y dejar fuera a todos los demás.
Construye un receptor que no se caiga
- Verifica la firma antes que nada. Calcula la firma esperada a partir del cuerpo sin procesar y de tu secreto, compárala en tiempo constante y rechaza todo lo que no coincida antes de analizarlo.
- Responde rápido. Devuelve un 2xx en uno o dos segundos. Haz el trabajo real desde una cola, para que un CRM lento no provoque reintentos.
- Guarda los ID de evento y sáltate los que ya hayas visto. Los reintentos son normales; procesar dos veces es un error tuyo.
- Asigna los campos de forma explícita. Pasa el slug, el destino, las etiquetas y las marcas de tiempo que necesites a tu propio esquema. No guardes la carga útil entera como dato de referencia; es una notificación, no un registro.
- Registra cada envío con su ID y su resultado. Así, cuando el registro de la plataforma diga «entregado» y tu sistema diga que no pasó nada, podrás averiguar adónde fue.
- Avisa cuando haya silencio. Si un endpoint que suele recibir eventos cada hora pasa un día callado, algo se ha roto en uno de los dos lados.
Antes de la primera campaña real, prueba con un endpoint de staging y con el envío de prueba de la plataforma. Crea un enlace, edítalo, elimínalo y comprueba que llegan los tres eventos.
Protege los datos
Las cargas útiles de los webhooks describen enlaces y secretos, no personas. Que siga siendo así.
- No pongas nunca datos personales en los slugs ni en las etiquetas de los enlaces, porque viajarán en cada carga útil sobre ese enlace.
- Restringe el endpoint al tráfico de la plataforma mediante la firma y, cuando se pueda, por dirección de origen.
- Guarda el secreto de firma en un gestor de secretos, no en el archivo de configuración del receptor, y rótalo de forma periódica. Si tienes que dar el secreto a un colaborador externo que construye el receptor, envíalo con un enlace secreto de un solo uso. La guía del secreto de firma de webhooks explica esa entrega.
- Ten en cuenta el consentimiento cuando los datos de clics llegan a un CRM. Un registro de clic vinculado a un cliente es un dato personal según la mayoría de las normas de privacidad.
Mide la propia integración
- Porcentaje de envíos correctos, según el registro de la plataforma.
- Retraso de procesamiento, desde la marca de tiempo del evento hasta el registro en tu sistema.
- Porcentaje de duplicados, que debe ser bajo pero nunca cero.
- Conciliación: una vez por semana, compara el número de enlaces y el total de clics de la API con lo que tienen tus sistemas. Una desviación indica un envío perdido o un error en el receptor.
Una plataforma de seguimiento de enlaces con webhooks permite que tus enlaces formen parte del resto de tus sistemas. Elige una que firme lo que envía, que te diga exactamente qué eventos existen y que te dé una API para las cifras. Después construye el receptor como si los reintentos fueran lo normal, porque lo son.