Passer au contenu principal
Cette page liste ce que Boble applique sur chaque livraison et quelques habitudes à adopter sur votre endpoint.

​
Ce que Boble applique

​
HTTPS uniquement

Les URLs en http:// sont refusées au moment de l’enregistrement et à nouveau au moment de la livraison. Seuls les endpoints en https:// sont acceptés.

​
Les réseaux privés sont bloqués

Quand vous configurez l’URL, Boble refuse les hôtes qui ressemblent à des adresses locales ou de réseau privé (localhost, 127.0.0.0/8, 10.0.0.0/8, 172.16-31, 192.168.0.0/16, 169.254.0.0/16, et les adresses IPv6 link-local / ULA). Ça évite de pointer un webhook par accident sur un service interne.

​
Timeout de 10 secondes

Si votre endpoint met plus de 10 secondes à répondre, Boble abandonne. La livraison est marquée comme échouée avec une erreur de timeout dans votre log d’événements, et vous pouvez la rejouer plus tard. C’est aussi pour ça que votre handler doit être rapide — répondez 200 d’abord, puis faites le travail lourd en tâche de fond.

​
Livraison en best-effort

Boble ne réessaie pas automatiquement une livraison échouée. L’événement en échec reste dans votre log jusqu’à ce que vous le renvoyiez manuellement.

​
Capture de la réponse

Boble stocke les 4 premiers Ko de ce que votre endpoint répond. C’est utile pour déboguer une livraison échouée depuis le dashboard — vous voyez le message d’erreur exact que votre service a renvoyé. Les réponses plus longues sont simplement tronquées.

​
Ce que vous devriez faire

​
Toujours vérifier la signature

Même pour les événements de test. Voir Vérification de signature.

​
Répondre vite

Répondez 200 aussi vite que possible — idéalement bien en dessous d’une seconde. Si votre handler doit appeler un autre service (envoyer un message Discord, créer un contact Mailchimp), enfilez le travail dans une file d’attente et acquittez d’abord. Sinon vous risquez de taper le timeout de 10 secondes et de voir votre événement marqué en échec.

​
Gérer les renvois proprement

Quand vous renvoyez un événement manuellement, Boble envoie une livraison flambant neuve avec les mêmes données mais un nouvel id d’enveloppe. Si votre handler n’y prend pas garde, ça peut appliquer deux fois certains effets de bord (envoyer deux fois le même email de bienvenue, créer deux contacts). Le pattern sûr est de dédupliquer sur une valeur dérivée de data.object — typiquement data.object.id combiné au type de l’événement. Voir Structure du payload.

​
Régénérer la clé en cas de fuite

Si vous soupçonnez que la clé de signature a été exposée (fichier de log fuité, ancien prestataire avec accès à vos variables d’environnement), régénérez-la depuis votre dashboard. Toutes vos promotions partagent la même clé, donc une seule régénération couvre tout.