Hasta ahora, saber si una publicación había salido significaba preguntar. Llamabas a la API, comprobabas el estado y volvías a llamar más tarde. Funciona, pero es una consulta repetida: o preguntas demasiado a menudo y desperdicias solicitudes, o preguntas demasiado poco y te enteras tarde. Los webhooks invierten la lógica. Le das una URL a sona.to y sona.to te llama en el momento en que ocurre algo. Ya están disponibles en todos los planes.
Hay cuatro eventos a los que suscribirse, y cubren los resultados que merecen una reacción: publicación publicada, publicación fallida, auditoría del sitio completada y auditoría del sitio fallida. Tú eliges cuáles recibe cada webhook, de modo que un avisador de Slack puede escuchar solo los fallos mientras un sistema de informes lo recibe todo. La carga útil usa los mismos nombres de campo que devuelve la API REST, así que lo que ya procesas de una solicitud GET sigue funcionando igual.
Configurarlo lleva un minuto. Abre la página API de tu panel, pega la URL que te dio tu herramienta, marca los eventos que quieras y guarda. La clave de firma aparece una sola vez en ese momento. Cópiala entonces, porque no se vuelve a mostrar.
Esa clave es lo que te permite saber que una solicitud es auténtica. Cada envío lleva una cabecera de firma con una marca de tiempo y un HMAC SHA-256 de esa marca de tiempo y del cuerpo de la solicitud, calculado con tu clave. Recalcúlalo por tu lado y compara ambos con una función de tiempo constante. Como la marca de tiempo forma parte de lo firmado, una solicitud capturada no puede reenviarse contra ti más tarde. Rechaza todo lo que tenga más de unos minutos y listo.
Los envíos no se rinden al primer problema. Si tu endpoint está caído o devuelve un error, la solicitud se reintenta a los 60 segundos, luego a los 5 minutos y luego a los 30 minutos. Cada intento queda registrado con su código de estado y su duración, así que un endpoint que se comporta mal es algo que puedes examinar en lugar de adivinar. Un endpoint que sigue fallando se desactiva automáticamente, y puedes volver a activarlo una vez arreglado.
El sitio evidente al que apuntarlo es una plataforma de automatización. Zapier, Make y n8n te dan una URL de webhook para pegar, y el evento llega en JSON listo para conectarlo con lo que venga después: un mensaje en un canal, una fila en una hoja de cálculo, una tarea en un gestor. Tu propio servidor funciona exactamente igual, sin plataforma de por medio.
Una nota sobre lo que sona.to acepta. El destino tiene que usar https y tiene que ser una dirección pública. Una URL que apunta a una red privada se rechaza, tanto al guardarla como en el momento del envío, y no se siguen redirecciones. Si alojas un receptor en una red local, ponlo detrás de un nombre de host público o un túnel.
Los webhooks se suman a la API REST y al servidor MCP como la tercera forma de manejar sona.to desde fuera del panel. La API sirve para preguntar, MCP sirve para que te pregunte un asistente de IA, y los webhooks sirven para que te avisen. Todos los detalles, incluido un ejemplo de verificación de firma, están en la documentación de la API.