Votre CRM apprend qu’une affaire est clôturée. Votre outil de support enregistre le ticket. Le service que vous avez construit l’apprend à la prochaine exécution de son cron, si le polling ne l’a pas manqué. Streaming est le canal push de Pathbound : quand un événement se déclenche ou qu’un contact ou une entreprise change, nous envoyons un POST à votre endpoint, en général quelques secondes après que le changement arrive sur le profil.
Ce sont les mots d’une équipe qui mettait un agent sur des conversations client en cours, à propos de la copie du client que lisaient ses outils. Chaque système en aval a sa version du même problème. Vous pouvez interroger une API pour repérer les changements, mais il vous faut alors maintenir un processus de polling, un curseur et un budget de limite de débit pour chaque ressource, et l’image n’est jamais plus fraîche que la dernière exécution. La plupart des équipes se contentent du job nocturne, et d’un client vieux d’un jour partout sauf dans l’outil source.
Pathbound sert les mêmes profils à identité résolue de trois façons. L’API REST renvoie un instantané quand votre code le demande. Le serveur MCP répond aux questions de votre agent sous forme d’appels d’outil. Streaming inverse le sens : Pathbound pousse les changements de données clients vers votre endpoint dès qu’ils atteignent le profil, et tenir un système externe à jour cesse d’être une tâche de polling.
Récupérez un instantané quand votre code le demande. Authentification Bearer, JSON en entrée, JSON en sortie.
Votre agent lit les profils, les chronologies et l’historique des conversations sous forme d’appels d’outil.
Un POST vers votre endpoint quand un événement se déclenche ou qu’une fiche change. Vous ne demandez plus : nous vous prévenons.
Streaming est la version Pathbound des webhooks de données clients : un flux couvre un type de données sur toutes les sources connectées, au lieu d’un webhook par outil. Les changements de contacts et d’entreprises sont capturés quelle que soit leur origine : synchronisations d’intégrations qui créent ou enrichissent des fiches depuis votre CRM et le reste, modifications manuelles, envois de formulaires et l’API.
| Type de données | Types de changement | Se déclenche quand |
|---|---|---|
| Événements | un nom d’événement, ou tous les événements | le snippet d’événements ou une intégration enregistre un événement |
| Contacts | création, mise à jour, suppression, ou tous les changements | un contact unifié est créé, modifié ou supprimé |
| Entreprises | création, mise à jour, suppression, ou tous les changements | une entreprise unifiée est créée, modifiée ou supprimée |
Une livraison est un POST avec un corps JSON. Définissez un secret de signature et chaque requête porte X-Pathbound-Signature, un HMAC-SHA256 du corps brut que vous pouvez vérifier en quelques lignes. Le tableau de bord journalise chaque livraison, flux par flux : code de réponse, latence, corps et nombre de tentatives.
{
"id": "ec_abc123",
"type": "contact.updated",
"resource": "contact",
"action": "updated",
"timestamp": "2026-06-08T12:00:00.000Z",
"source": "hubspot",
"object": {
"contact_id": "ct_abc",
"properties": {
"email": "[email protected]",
"jobtitle": "VP Engineering",
"lifecyclestage": "mql"
}
},
"changed_fields": ["jobtitle", "lifecyclestage"]
}L’objet d’une livraison de contact correspond à GET /v1/contacts/:id. Un miroir construit sur Streaming concorde avec l’API.
Le snippet d’événements enregistre une page vue sur /pricing et le visiteur s’identifie comme contact. Un flux filtré sur cette URL envoie un POST à votre service pendant qu’il est encore sur le site, pas dans le rapport de demain.
Répliquez contacts et entreprises dans Postgres, ou ailleurs, à mesure que les intégrations les enrichissent. Le payload porte la fiche complète et les champs modifiés ; dédupliquez sur id, réconciliez par updated_at, et le miroir reste fidèle.
Un filtre sur le champ modifié lifecyclestage ne se déclenche que lorsque l’étape change, quelle que soit la source, qu’un commercial ait modifié le CRM ou qu’un formulaire ait fait progresser le lead. La livraison arrive dans n8n ou dans votre propre worker et lance l’exécution.
Les lectures de votre agent passent par le MCP données clients, les sources qui alimentent le profil sont dans les intégrations, et la référence complète des livraisons est dans la documentation Streaming.
Les trois servent les mêmes profils. L’API REST renvoie un instantané quand votre code le demande ; le serveur MCP répond aux questions de votre agent sous forme d’appels d’outil ; Streaming inverse le sens : Pathbound envoie un POST à votre endpoint quand quelque chose change, et vos systèmes réagissent sans rien demander. Une livraison de contact porte un objet de même forme que GET /v1/contacts/:id : un miroir construit sur Streaming correspond donc à ce que l’API renverrait.
Créez un flux dans le tableau de bord : choisissez les contacts comme type de données, choisissez création, mise à jour, suppression ou tous les changements, puis indiquez votre endpoint HTTPS. Dès lors, Pathbound envoie en POST un corps JSON avec la fiche complète, la source du changement et les champs modifiés quand un diff par champ est disponible. Les changements sont capturés depuis toutes les sources : synchronisations d’intégrations, modifications manuelles, envois de formulaires et API.
Définissez un secret de signature sur le flux. Chaque livraison porte alors X-Pathbound-Signature, un HMAC-SHA256 du corps brut de la requête. Recalculez-le avec votre secret et comparez à temps constant ; la documentation fournit des exemples en Node et en Python. Considérez l’URL de destination comme publique et vérifiez chaque requête.
Une livraison en échec (une réponse autre que 2xx, un délai dépassé ou une erreur réseau) est retentée jusqu’à 3 fois, avec des délais de 1 s, 10 s puis 60 s. Après une longue série d’échecs consécutifs, le flux se met en pause de lui-même pour ne pas marteler un endpoint hors service ; réactivez-le depuis le tableau de bord une fois votre endpoint rétabli. Chaque livraison y est journalisée avec le code de réponse, la latence, le corps et le nombre de tentatives.
Les livraisons partent en général quelques secondes après qu’un changement arrive sur le profil. Quand le snippet d’événements enregistre un événement ou qu’une source met à jour un contact, le changement est capturé, regroupé avec les autres changements rapprochés sur la même fiche, puis livré. Ce que Streaming ne peut pas faire, c’est devancer l’outil en amont : si un CRM ne signale une modification à Pathbound qu’à sa prochaine synchronisation, le flux se déclenche quand nous l’apprenons.
Oui. Les flux d’événements se filtrent par nom d’événement et par sous-chaînes d’URL : par exemple, seules les pages vues dont l’URL contient /pricing. Les flux de contacts et d’entreprises se filtrent par champs modifiés, pour qu’un flux ne se déclenche que lorsque lifecyclestage change, et par source, pour qu’il ne se déclenche que sur les changements venus d’une origine donnée. Quand aucun diff par champ n’est disponible, le filtre sur les champs modifiés laisse passer le changement, pour que vous ne manquiez aucune mise à jour sans le savoir.
Inscrivez-vous, connectez un CRM ou ajoutez le snippet d’événements, puis pointez votre client MCP sur mcp.pathbound.ai/mcp.