Jusqu'ici, savoir si une publication était bien partie demandait de poser la question. Vous appeliez l'API, vérifiiez le statut, puis rappeliez plus tard. Ça marche, mais c'est de l'interrogation : soit vous demandez trop souvent et gaspillez des requêtes, soit vous demandez trop rarement et l'apprenez tard. Les webhooks inversent la logique. Vous donnez une URL à sona.to, et sona.to vous appelle dès qu'il se passe quelque chose. Ils sont disponibles dès maintenant sur tous les forfaits.
Quatre événements sont proposés, et ils couvrent les cas qui méritent une réaction : publication réussie, publication échouée, audit de site terminé et audit de site échoué. Vous choisissez lesquels chaque webhook reçoit, si bien qu'une alerte Slack peut n'écouter que les échecs pendant qu'un pipeline de reporting prend tout. La charge utile reprend les mêmes noms de champs que l'API REST, donc ce que vous analysez déjà depuis une requête GET fonctionne sans changement.
La mise en place prend une minute. Ouvrez la page API de votre tableau de bord, collez l'URL fournie par votre outil, cochez les événements voulus et enregistrez. La clé de signature s'affiche une seule fois à ce moment-là. Copiez-la tout de suite, car elle n'est plus jamais affichée.
Cette clé est ce qui vous permet de savoir qu'une requête est authentique. Chaque envoi porte un en-tête de signature contenant un horodatage et un HMAC SHA-256 de cet horodatage et du corps de la requête, calculé avec votre clé. Recalculez-le de votre côté et comparez les deux avec une fonction à temps constant. Comme l'horodatage fait partie des données signées, une requête capturée ne peut pas être rejouée contre vous plus tard. Rejetez tout ce qui a plus de quelques minutes et c'est réglé.
Les envois n'abandonnent pas au premier problème. Si votre point de terminaison est indisponible ou renvoie une erreur, la requête est retentée après 60 secondes, puis 5 minutes, puis 30 minutes. Chaque tentative est enregistrée avec son code de statut et sa durée, si bien qu'un point de terminaison capricieux devient quelque chose que vous pouvez examiner plutôt que deviner. Un point de terminaison qui échoue continuellement est désactivé automatiquement, et vous pouvez le réactiver une fois corrigé.
L'endroit évident où le pointer est une plateforme d'automatisation. Zapier, Make et n8n vous donnent tous une URL de webhook à coller, et l'événement arrive au format JSON, prêt à être relié à la suite : un message dans un canal, une ligne dans un tableur, une tâche dans un outil de suivi. Votre propre serveur fonctionne exactement pareil, sans plateforme intermédiaire.
Une remarque sur ce que sona.to accepte. La destination doit utiliser https et doit être une adresse publique. Une URL qui pointe vers un réseau privé est refusée, à l'enregistrement comme au moment de l'envoi, et les redirections ne sont pas suivies. Si vous hébergez un récepteur sur un réseau local, placez-le derrière un nom d'hôte public ou un tunnel.
Les webhooks rejoignent l'API REST et le serveur MCP comme troisième façon de piloter sona.to depuis l'extérieur du tableau de bord. L'API sert à demander, MCP sert à être interrogé par un assistant IA, et les webhooks servent à être prévenu. Tous les détails, dont un exemple de vérification de signature, sont dans la documentation de l'API.