Prérequis
- Une clé API Pubrio avec accès aux monitors
- Un point de terminaison HTTPS accessible publiquement (ou une URL de test depuis usewebhook.com)
Étape 1 : créer un Monitor avec une destination webhook
headers ajoute des en-têtes HTTP personnalisés à chaque envoi (utile pour l’authentification). L’objet body ajoute des champs personnalisés à la racine de la charge utile du webhook.
Étape 2 : valider votre connexion webhook
Utilisez le point de terminaison Validate Webhook pour tester que votre point de terminaison est joignable. Cela envoie une charge utile d’exemple avec des données de substitution — aucun crédit n’est consommé, aucun signal réel n’est récupéré.Étape 3 : tester avec des données réelles
Une fois la connexion validée, déclenchez une exécution réelle avec le point de terminaison Process Try. Cela récupère de vrais signaux et les livre à votre webhook — utiliseztried_at avec une date passée récente pour vous assurer que des données sont disponibles :
Contrairement à validate, le point de terminaison try exécute un vrai scan et consomme des crédits. Utilisez-le pour vérifier que les charges utiles réelles arrivent correctement et obtenir une estimation rapide des résultats avant le déclenchement du scan planifié.
Étape 4 : vérifier les signatures
Chaque monitor dispose d’une signature unique permettant de vérifier que les charges utiles entrantes proviennent bien de Pubrio.monitor.monitor_id des charges utiles entrantes pour en vérifier l’authenticité.
Structure de la charge utile du webhook
Les charges utiles diffèrent selon ledetection_mode du monitor :
- Signal First
- Company First
En mode Chaque entrée de signal contient les détails du signal ainsi que les entreprises et personnes enrichies associées.
signal_first, la charge utile contient un tableau signals de premier niveau :Les champs
body personnalisés issus de destination_config apparaissent à la racine de la charge utile (par exemple, "pipeline": "my-webhook" s’il est configuré dans votre destination).Signaux d’expansion
Aux côtés dejobs, news et advertisements, un monitor peut surveiller les signaux d’expansion — la preuve datée qu’une entreprise entre sur un nouveau marché ou s’y développe. Ajoutez expansions à signal_types :
froms et tos pour le corridor, plus stages, scopes, momentum, freshness, signal_types, signal_subtypes, signal_strengths, source_types et window_days. Résolvez les slugs valides depuis Expansion Reference.
Les signaux d’expansion sont regroupés par entreprise et par marché, et non par signal. Une entreprise qui entre sur deux marchés produit deux entrées, chacune portant sa propre chronologie de signaux pour ce marché.
Charge utile des signaux d’expansion
Destination e-mail
Pour les équipes qui préfèrent la livraison par e-mail, définissezdestination_type sur "email" :
Pubrio prend en charge la livraison d’e-mails en marque blanche pour les agences et les équipes. Contactez-nous pour en savoir plus sur la personnalisation du domaine expéditeur et de l’image de marque.
Dépannage
Le webhook ne reçoit pas de charges utiles
Le webhook ne reçoit pas de charges utiles
- Vérifiez que votre point de terminaison est accessible publiquement (pas derrière un pare-feu ou un VPN)
- Assurez-vous qu’il renvoie un code de statut
200— les autres codes sont traités comme des échecs - Utilisez le point de terminaison Validate Webhook pour tester la connectivité
- Consultez les Statistic Logs pour les messages d’erreur et les codes de réponse
Monitor mis en pause après des échecs
Monitor mis en pause après des échecs
Si votre webhook renvoie systématiquement des codes non-200, le monitor se met en pause après avoir atteint
max_failure_trigger échecs consécutifs. Corrigez le problème puis réactivez via Update Monitor.Charges utiles en double
Charges utiles en double
Si une livraison échoue et que des tentatives sont configurées, vous pouvez recevoir plusieurs fois la même charge utile. Utilisez
triggered_at ou l’identifiant de journal pour dédupliquer de votre côté.Charge utile trop volumineuse
Charge utile trop volumineuse
Réduisez
max_records_per_trigger pour limiter le nombre d’enregistrements par livraison. Vous pouvez aussi restreindre vos filtres pour réduire le volume de signaux correspondants.
