En dos líneas: un webhook le avisa a otra herramienta cada vez que pasa algo en MB Suite: entra un lead, un trato cambia de etapa, sale una publicación. Lo creas en Configuración > API y MCP, pestaña Webhooks: eliges la dirección y los eventos, y MB Suite los envía firmados, reintenta si tu destino no responde y te deja el registro de cada entrega.

¿Para qué sirve un webhook?

Sin webhooks, para que otro sistema se entere de un lead nuevo, alguien tiene que copiarlo a mano o esa herramienta tiene que consultar MB Suite a cada rato. Con un webhook es al revés: en cuanto pasa el evento, MB Suite manda los datos a la dirección que le diste. Así, cada lead que entra por tus formularios o tus anuncios llega a tu ERP o a tu hoja de cálculo, cada trato que avanza de etapa dispara el flujo que armaste en Make y cada publicación que sale puede quedar anotada donde tu equipo la sigue, salvo lo que los términos de una plataforma no dejan enviar a un webhook (ver más abajo).

Los webhooks de este artículo salen de MB Suite. Si buscas lo contrario —que otra herramienta le mande leads a tu CRM—, eso se arma con una fuente de leads Webhook genérico: ver Conectar formularios y anuncios, y saber de qué campaña vino cada lead.

¿Quién puede crear webhooks?

La pestaña Webhooks de API y MCP la ven solo el owner y los admins del workspace —o de la Cuenta, si el webhook es de una Cuenta—; el resto del equipo ve solo MCP y Documentación. Para crearlos, la API y el MCP tienen que estar habilitados en el workspace. Si alguien los apagó, los webhooks dejan de enviar eventos nuevos y Crear webhook queda deshabilitado hasta que se vuelvan a habilitar; lo que ya estaba en cola espera hasta 72 horas (ver API, MCP y webhooks). Los webhooks de un workspace pueden escuchar también a sus Cuentas; los de una Cuenta escuchan solo lo que pasa en ella. Cada organización puede tener a la vez tantos webhooks activos como permita su plan: el contador de arriba de la tabla muestra cuántos tienes sobre el máximo, y los cupos de cada plan están en Precios.

Un webhook depende de quien lo creó: si esa persona deja la organización o deja de ser owner o admin, el webhook se desactiva y los owners y admins reciben un aviso en las notificaciones. En la tabla figura como Desactivado, con el motivo al pasar el cursor, y cualquier owner o admin puede reactivarlo.

¿Cómo creo un webhook?

Ve a Configuración > API y MCP y abre la pestaña Webhooks.
Presiona Crear webhook.
En URL de destino, pega la dirección que te dio tu herramienta. Tiene que empezar con https:// y ser pública: MB Suite la revisa mientras escribes y, si sirve, muestra Destino válido con el nombre del servidor; si no, el campo te dice por qué. No se aceptan direcciones privadas ni internas.
Si quieres, escribe una Descripción para recordar para qué es (por ejemplo, «Leads a Odoo»).
En Eventos, marca los que quieres recibir. Arriba hay un buscador; debajo, los eventos agrupados por área, con el CRM primero, y cada área y cada módulo tienen su casilla para marcarlos todos. Cada evento trae su descripción y Ver ejemplo, que muestra cómo llega, con datos de ejemplo. Todos los eventos marca los de todos los módulos de una vez: marca solo los que necesitas.
Si estás en un workspace y también quieres los eventos de tus Cuentas, activa Escuchar también a las Cuentas y elige Todas las Cuentas (incluye las que crees después) o Elegir Cuentas. Cada evento trae en org_id la organización donde pasó, para que sepas de qué Cuenta viene.
Si tu destino lo necesita, abre Avanzado (más abajo, qué hay ahí).
Presiona Crear webhook. En la misma ventana aparece el secreto de firma: cópialo con Copiar, guárdalo y cierra con Listo, que se habilita cuando lo copias o marcas Ya lo guardé.

El secreto —empieza con whsec_— se muestra una sola vez y no se puede volver a ver. Guárdalo donde tu sistema guarda sus secretos, no en un documento compartido. Si lo pierdes, usa Rotar secreto para obtener uno nuevo.

¿Qué hay en Avanzado?

Formato: Completo (recomendado) manda el registro entero —el trato, la persona, la empresa— y es el más cómodo para Make u Odoo; Solo IDs manda solo los identificadores, y tu sistema consulta el resto. Si un evento completo pasa de 256 KB, llega solo con IDs, con truncated: true dentro de data.

Versión de la API: déjala como viene. Cada entrega la informa en el encabezado MB-Api-Version.

Encabezados fijos: hasta 5 pares de nombre y valor que viajan en cada entrega, para destinos que exigen su propio token. Los valores no se vuelven a mostrar: al editar el webhook ves solo los nombres, y para cambiarlos usas Reemplazar encabezados. No pueden reemplazar los encabezados que pone MB Suite (los que se listan más abajo).

¿Cómo pruebo un webhook?

En el menú Acciones de la fila (los tres puntos), elige Enviar evento de prueba. A tu destino llega un evento webhook.test, firmado y con los mismos encabezados que uno real, y lo ves en Ver entregas. Sirve para comprobar que tu sistema lo recibe y que tu verificación de la firma funciona. El evento de prueba llega aunque el webhook esté desactivado: así puedes probar tu destino antes de reactivarlo. Mientras la API y el MCP están apagados no sale nada, tampoco el evento de prueba ni un reenvío.

El evento de prueba trae un mensaje corto, no un lead ni un trato. Para ver la forma real de un evento sin tocar tus datos, usa la organización de práctica: cuando tu workspace la tiene (se crea con la primera API key de prueba, ver API keys), arriba de la tabla aparece el selector Producción / Prueba. En Prueba creas los webhooks de la organización de práctica: reciben solo los eventos de lo que hacen las API keys de prueba, y se entregan de verdad, con la misma firma.

Sin la organización de práctica, también puedes provocar un evento real tú mismo: carga un prospecto a mano o mueve un trato de etapa.

¿Qué eventos puedo recibir?

Hay eventos de casi todos los módulos de MB Suite. Cada uno dice en su descripción cuándo se dispara —algunos solo cuando el cambio llega por la API, el MCP o MIA—, así que léela antes de armar tu flujo. Estos son los del CRM, los más usados, y lo que dispara cada uno:

Evento	Cuándo llega
`crm.lead.created`	Entra un lead nuevo: por una fuente de leads (tu formulario de MB Suite, un anuncio con formulario de Meta, tu página de reservas, el webhook genérico o un mensaje directo o un comentario de Instagram o Facebook que entra al CRM), con el primer mensaje de WhatsApp de un contacto nuevo, por la API, o porque alguien cargó un prospecto a mano. Trae a la persona, el prospecto o el trato en que se convirtió y la fuente. También llega para alguien que ya estaba en el CRM, siempre que el lead le cree un prospecto o un trato nuevo. No llega cuando no se crea nada nuevo: el mismo lead enviado otra vez, una fuente configurada en Ignorar duplicado o un lead que va al prospecto o al trato que la persona ya tenía. Todavía no llega con un mensaje o un comentario de redes de un perfil que ya está vinculado a una persona. Tampoco llega con los leads de Google Ads, de TikTok o de LinkedIn (sus formularios, y los mensajes directos y los comentarios de TikTok): los términos de esas plataformas no dejan enviar sus datos a un webhook.
`crm.deal.created`	Se crea un trato: a mano en el CRM, por la API, al convertir un prospecto en trato (desde la pantalla, la API o el Setter de IA) o cuando una fuente de leads manda el lead directo a un pipeline. En este último caso también llega `crm.lead.created`, con el trato adentro.
`crm.deal.stage_changed`	Un trato pasa a otra etapa o a otro pipeline: desde la pantalla, en un movimiento en lote o desde una secuencia. Trae la etapa y el pipeline nuevos y, en `previous`, los anteriores, con sus nombres. Los movimientos que hace una fusión o la eliminación de una etapa no lo disparan.
`crm.deal.won`	Un trato se marca como ganado. `previous_status` dice en qué estado estaba.
`crm.deal.lost`	Un trato se marca como perdido, con el motivo de pérdida si se eligió uno.
`crm.deal.reopened`	Un trato ganado o perdido vuelve a estar abierto.
`crm.deal.archived`	Un trato se archiva (`archived: true`) o se desarchiva (`archived: false`) desde su ficha o por la API. Archivarlo junto con una persona o una empresa no lo dispara.
`crm.deal.updated`	Se editan otros datos de un trato: título, valor, responsable, empresa, etiquetas, campos personalizados… `changed_fields` dice cuáles. Una etapa nueva, ganar, perder, reabrir o archivar mandan su propio evento, no este, y los cambios de etiquetas o de responsable en lote no lo disparan.
`crm.deal.deleted`	Se elimina un trato, uno por uno o varios a la vez. Trae la última copia del trato, que queda 30 días en la Papelera del CRM. Eliminarlo junto con sus registros vinculados, o fusionarlo, no lo dispara.
`crm.person.created`	Alguien crea una persona en el CRM, o se crea por la API. Una persona que llega como lead nuevo por una fuente se envía como `crm.lead.created`, y las importaciones no lo disparan.
`crm.person.updated`	Alguien edita los datos de una persona desde su ficha o por la API. `changed_fields` dice qué cambió. Los cambios en lote no lo disparan.
`crm.person.deleted`	Se elimina una persona, una por una o varias a la vez; queda 30 días en la Papelera. Eliminarla junto con sus registros vinculados, o fusionarla, no lo dispara.
`crm.company.created`	Alguien crea una empresa en el CRM, o se crea por la API. Las empresas que crea una fuente de leads o una importación no lo disparan.
`crm.company.updated`	Alguien edita los datos de una empresa desde su ficha o por la API. `changed_fields` dice qué cambió. Los cambios en lote no lo disparan.
`crm.company.deleted`	Se elimina una empresa, una por una o varias a la vez; queda 30 días en la Papelera. Eliminarla junto con sus registros vinculados, o fusionarla, no lo dispara.
`crm.activity.created`	Alguien registra una actividad —nota, tarea, llamada, reunión o respuesta— en un trato, una persona, una empresa o un prospecto, en el CRM o por la API. Lo que se registra solo (correos sincronizados de un buzón, mensajes de WhatsApp o de redes, y lo que registran las secuencias, el marcador o el Equipo IA) no lo dispara.
`webhook.test`	Solo cuando presionas Enviar evento de prueba, y solo a ese webhook.

Tampoco llega ningún evento de un trato o de una persona que entró por un formulario de Google Ads, por TikTok o por LinkedIn —ni cuando el trato se crea, cambia de etapa o se gana—, ni de una persona o una empresa que se creó o se completó por TikTok o por LinkedIn: como con crm.lead.created, los términos de esas plataformas no dejan enviar sus datos a un webhook. Las empresas que se crearon o se completaron con un formulario de Google Ads, y las personas que se completaron con uno, llegan sin las respuestas del formulario en sus campos personalizados. Y en todos los eventos del CRM, una atribución a Google Ads, LinkedIn o TikTok llega con sus ids, sin los nombres de la campaña, el grupo, el anuncio y el formulario (ni la palabra clave de Google), y las personas y las empresas llegan sin su enlace de LinkedIn.

Lo que se elimina se puede recuperar durante esos 30 días desde la Papelera del CRM. Y un webhook recibe lo que pasa desde que lo creas —puede tardar hasta un minuto en empezar— y no trae el historial de antes.

Si traes leads históricos con el backfill de una fuente de leads, cada lead que crea un prospecto o un trato nuevo, aunque la persona ya estuviera en el CRM, también se envía como crm.lead.created. Tenlo en cuenta antes de lanzarlo: tu destino recibe un evento por cada lead que crea algo nuevo; un duplicado no envía nada. El backfill de una fuente de Google Ads o de LinkedIn no lo envía, igual que el resto de sus leads.

Algunos ejemplos de otros módulos:

Evento	Cuándo llega
`web_forms.submission.received`	Un formulario web publicado recibe una respuesta real. Trae lo que se envió, el lead del CRM que creó si el formulario está vinculado a una fuente de leads y la atribución de anuncios. Las respuestas que descartan los filtros de spam y los envíos de prueba desde el editor no lo disparan.
`social_planner.post.published`	Una publicación salió en todas sus redes, al momento o en su horario programado. Trae el enlace cuando la red lo da. No llega con una publicación que va a LinkedIn, a TikTok o a Google Business, aunque también vaya a otras redes: sus términos no dejan enviar sus datos a un webhook.
`social_planner.post.failed`	Una publicación no se pudo publicar en ninguna red después de los reintentos automáticos, con el motivo en cada red. Como el anterior, no llega con una publicación que va a LinkedIn, a TikTok o a Google Business.
`social_inbox.item.received`	Llega al Inbox un comentario, un mensaje directo o una mención de Instagram o Facebook (los de LinkedIn y TikTok no lo disparan: sus términos no dejan enviar sus datos a un webhook). Los mensajes directos que pertenecen al CRM y lo que se clasifica como spam no lo disparan.
`email_marketing.campaign.sent`	Sale una campaña de email —desde la pantalla, por la API o a su hora programada—, con cuántos mensajes quedaron en cola.
`task_management.comment.added`	Alguien comenta una tarea, desde la app, la API, el MCP o MIA. Los comentarios en tareas privadas no lo disparan.
`reports.pdf.ready`	Terminó de generarse el PDF de un reporte, desde la pantalla de Reportes o por la API. El evento no trae el archivo: se descarga por la API, salvo que el reporte tenga bloques de una plataforma cuyos términos no lo permiten (ver API, MCP y webhooks).
`alerts.alert.triggered`	La evaluación de cada hora encuentra que se cumple la condición de una alerta de métrica, una vez por disparo. No llega con una alerta sobre una métrica de Google Ads, Business Profile, LinkedIn, TikTok o YouTube: sus términos no dejan enviar sus datos a un webhook.

En los otros módulos, un evento con datos de Google Ads, Business Profile, LinkedIn, TikTok o YouTube tampoco llega, o llega sin esos datos: por ejemplo, un cambio en una de sus cuentas publicitarias, un envío cuyos PDF incluyen sus cuentas, una conexión de LinkedIn o de TikTok que se desconecta o el gasto de un plan de medios. Los eventos que solo traen esos datos, como los de Local SEO o Auto-Budget, o la sincronización de costos de un plan de medios, no se ofrecen. Si un webhook ya estaba suscrito a uno de ellos, el evento sigue en su lista pero no llega, y un reintento o un reenvío de un evento con esos datos tampoco sale: la entrega queda como Cancelada.

La lista completa, con un ejemplo de cada evento, está en el selector (Ver ejemplo) y en la referencia de eventos de webhooks de la documentación.

¿Qué recibe mi sistema y qué tiene que responder?

Cada entrega es un POST con Content-Type: application/json. El cuerpo tiene siempre la misma forma: id (el del evento, evt_…), type, created_at, api_version, org_id y data, con los datos del evento en snake_case. Los encabezados traen MB-Signature (la firma), MB-Event-Id, MB-Event-Type, MB-Webhook-Id, MB-Delivery-Id, MB-Api-Version, Idempotency-Key y un User-Agent que empieza con MB-Suite-Webhooks.

Tu sistema tiene que responder con un código 2xx en menos de 10 segundos. Si tiene mucho que hacer, que responda primero y procese después. Cualquier otra respuesta, una redirección (3xx) o pasar los 10 segundos cuenta como falla y se reintenta.

Un mismo evento puede llegarte más de una vez: por ejemplo, si tu sistema lo procesó pero respondió tarde, o si lo reenvías. Usa su id —también viaja en Idempotency-Key— para no procesarlo dos veces.

¿Cómo verifico que el evento viene de MB Suite?

Cada entrega viaja firmada en el encabezado MB-Signature, con esta forma: t=1762000000,v1=5257a8…. t es el momento de la firma, en segundos Unix, y v1 es un HMAC-SHA256 en hexadecimal, calculado con tu secreto sobre t, un punto y el cuerpo exacto del request.

Lee el cuerpo del request tal como llegó, sin convertirlo antes a JSON: si lo conviertes y lo vuelves a armar, la firma ya no coincide.
Separa t y los valores v1 del encabezado.
Calcula el HMAC-SHA256 de t.cuerpo con tu secreto y compáralo con cada v1 usando una comparación de tiempo constante. Si alguno coincide, el evento viene de MB Suite.
Descarta el evento si t está a más de 5 minutos de tu hora actual: así nadie puede reenviarte una entrega vieja.

No hace falta escribirlo desde cero: debajo del secreto, Verificar la firma en tu servidor trae el código listo para Node, Python y PHP. Mientras se rota un secreto, el encabezado trae dos v1=, y vale cualquiera de los dos.

¿Cómo lo conecto con Make, Odoo o Monday?

Make. Crea un escenario que empiece con el módulo «Custom webhook»: Make te da una URL, que pegas en URL de destino. Después, en Make, haz clic en «Re-determine data structure» y usa Enviar evento de prueba para que aprenda el sobre; para la forma real de un lead o de un trato, provoca el evento. Make responde 200 en cuanto recibe, así que la entrega figura como Entregada aunque el escenario falle después. Como candado, lo más simple es un encabezado fijo (por ejemplo, X-Make-Token con un valor largo que inventes) y un filtro en el escenario que lo compare.

Odoo. En las versiones recientes, una regla de automatización con el disparador «On webhook» te da una URL para pegar en URL de destino. Para crear el lead, la acción tiene que ser de código Python («Execute Code»), que recibe el JSON en payload: el nombre, por ejemplo, está en payload['data']['person']['full_name'], y payload['id'] te sirve para no crear dos veces el mismo lead. Como la acción recibe el JSON ya leído, verificar la firma ahí no es práctico: trata la URL de Odoo como un secreto y no la compartas.

Monday. Monday no recibe webhooks de otros sistemas por su cuenta. Lo más directo es poner Make en el medio: un escenario que empieza con el webhook de MB Suite y sigue con el módulo de Monday que crea el ítem en tu tablero, con los campos de data (por ejemplo, data.person.full_name, data.deal.title o data.stage.name). También hay apps en el marketplace de Monday que reciben webhooks.

¿Qué pasa si mi sistema no responde?

MB Suite reintenta cada entrega que falla, con esperas cada vez más largas entre un intento y el siguiente: 5 minutos, 30 minutos, 2 horas, 5 horas, 10 horas y, desde ahí, cada 12 horas, hasta 11 intentos en unas 72 horas. Cuando un intento sale bien, esa entrega queda como Entregada y no se vuelve a mandar.

Si tu destino lleva 24 horas sin responder bien, el owner y los admins reciben un correo, y la tabla muestra debajo de la dirección «Sin responder desde…», con el tiempo que lleva fallando, y que se desactiva solo a las 72 horas. Si a las 72 horas sigue fallando, el webhook pasa a Desactivado por fallas: deja de recibir eventos, se cancelan sus entregas en cola y llegan otro correo y un aviso en las notificaciones.

Si todos tus webhooks dejan de entregar a la vez, el problema puede estar de nuestro lado: revisa developers.mb-suite.com/status, que muestra el estado de la API, el servidor MCP y los webhooks, con los incidentes en curso y los mantenimientos programados. Revisa también que nadie haya apagado la API y el MCP del workspace y que su suscripción siga paga y activa.

¿Cómo lo reactivo y recupero lo que no llegó?

Corrige lo que fallaba en tu destino. En Ver entregas tienes el código y la respuesta de cada intento.
En el menú Acciones del webhook, elige Reactivar.
Deja marcado Reenviar lo que falló antes de desactivarse —viene marcado— y confirma con Reactivar.
El webhook vuelve a recibir los eventos nuevos y, si marcaste el reenvío, las entregas que fallaron o quedaron canceladas en las 72 horas anteriores a que se desactivara vuelven a la cola, una sola vez cada una, de la más vieja a la más nueva. El mensaje de confirmación te dice cuántas se reenviaron.

Lo que pasa en MB Suite mientras un webhook está desactivado —por fallas o porque lo desactivaste tú— no se guarda para ese webhook, así que no se puede reenviar después. Al reactivarlo, recibe desde ese momento en adelante.

¿Cómo veo qué se envió y reenvío una entrega?

En el menú Acciones del webhook, elige Ver entregas. Se abre el panel Entregas con las últimas 100, de la más nueva a la más vieja.
Cada fila muestra el estado (Pendiente, Reintentando, Entregada, Fallida o Cancelada), el evento, el intento (por ejemplo, Intento 3/11), cuánto tardó y el código que respondió tu destino. Filtra con Todas, Fallidas, Entregadas o Pendientes.
Abre una entrega para ver el detalle: cada intento con su resultado, la Solicitud enviada (encabezados y cuerpo) y la Última respuesta de tu destino, hasta sus primeros 4 KB. La firma y los valores de tus encabezados fijos no se muestran.
Para mandarla otra vez, presiona Reenviar: sale una entrega nueva del mismo evento, marcada Reenvío, con su propia serie de reintentos. El webhook tiene que estar activo.

Los eventos y las entregas se guardan 30 días.

¿Cómo cambio el secreto sin cortar la integración?

En el menú Acciones del webhook, elige Rotar secreto.
Confirma con Rotar. Aparece el Secreto nuevo: cópialo y guárdalo, igual que el primero.
Cámbialo en tu sistema. Durante 24 horas, cada entrega lleva dos firmas v1= —una con el secreto nuevo y otra con el anterior— y vale cualquiera; pasado ese plazo, firma solo el nuevo.

¿Qué más puedo hacer con un webhook?

Desde el menú Acciones de la fila: Editar cambia la dirección (se vuelve a revisar), la descripción, los eventos, las Cuentas o lo de Avanzado, sin tocar el secreto; Desactivar lo pausa —deja de recibir eventos y se cancelan sus entregas en cola— hasta que lo reactives; Eliminar borra el webhook y su secreto, cancela lo que estaba en cola y no se puede deshacer. Todo esto funciona también mientras la API y el MCP están apagados.

Un webhook saca de MB Suite datos de tus contactos —nombres, correos, teléfonos— hacia el sistema que elijas. Suscríbete solo a los eventos que necesitas y envíalos a destinos que controles. El uso de los webhooks y el tratamiento de esos datos se rigen por nuestros Términos y Condiciones y nuestro Acuerdo de Tratamiento de Datos (DPA). Siguiente paso: Integraciones: qué puedes conectar y cómo funcionan.

¿Te quedan más dudas?

Pregúntale a MIA, el asistente de IA de MB Suite: lo abres con el botón MB AI (⌘J) en la barra superior. MIA conoce la sección en la que estás, así que puedes consultarle sobre lo que ves en pantalla, y también responde preguntas de cómo usar MB Suite.

Webhooks: avisa a tus otras herramientas en el momento en que algo pasa en MB Suite