The high-intent visitor
The events snippet records a page view on /pricing and the visitor identifies as a contact. A stream filtered to that URL POSTs to your service while they’re still on the site, not in tomorrow’s report.
Your CRM learns a deal closed. Your support desk logs the ticket. The service you built finds out on its next cron run, if the poller didn’t miss it. Streaming is Pathbound’s push channel: when an event fires or a contact or company changes, we send a signed POST to your endpoint—typically seconds after the change lands on the profile.
That’s a team putting an agent on live customer threads, describing the copy of the customer their tools were reading. Every downstream system has a version of the same problem. You can poll an API for changes, but then you own a poller, a cursor, and a rate-limit budget for each resource—and the picture is still only as fresh as the last run. Most teams settle for the nightly job, and a customer that’s a day old everywhere except the source tool.
Pathbound serves the same identity-resolved profiles three ways. The REST API returns a snapshot when your code asks. The MCP server answers your agent’s questions as tool calls. Streaming reverses the direction: Pathbound pushes customer data changes to your endpoint the moment they reach the profile, so keeping an external system current stops being a polling job.
Streaming is Pathbound’s take on customer data webhooks: one stream covers a data type across every connected source, not one webhook per tool. Contact and company changes are captured wherever they originate—integration syncs that create or enrich records from your CRM and the rest, manual edits, form submissions, and the API.
| Data type | Change types | Fires when |
|---|---|---|
| Events | an event name, or all events | the events snippet or an integration records an event |
| Contacts | created, updated, deleted, or all changes | a unified contact is created, changed, or removed |
| Companies | created, updated, deleted, or all changes | a unified company is created, changed, or removed |
A delivery is a POST with a JSON body. Set a signing secret and every request carries X-Pathbound-Signature, an HMAC-SHA256 of the raw body you can verify in a few lines. The dashboard logs every delivery per stream: response code, latency, body, and attempt count.
{
"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"]
}The object in a contact delivery matches GET /v1/contacts/:id. A mirror built on Streaming agrees with the API.
The events snippet records a page view on /pricing and the visitor identifies as a contact. A stream filtered to that URL POSTs to your service while they’re still on the site, not in tomorrow’s report.
Mirror contacts and companies into Postgres, or anywhere else, as integrations enrich them. The payload carries the full record and the changed fields; dedupe on id, reconcile by updated_at, and the mirror stays honest.
A changed-field filter on lifecyclestage fires only when the stage moves—from any source, whether a rep edited the CRM or a form promoted the lead. The delivery lands in n8n or your own worker and starts the run.
Reads for your agent live on the customer data MCP, the sources feeding the profile are in integrations, and the full delivery reference is in the Streaming docs.
All three serve the same profiles. The REST API returns a snapshot when your code asks; the MCP server answers your agent’s questions as tool calls; Streaming reverses the direction—Pathbound sends a POST to your endpoint when something changes, so your systems react without asking. A contact delivery carries the same object shape as GET /v1/contacts/:id, so a mirror built on Streaming matches what the API would return.
Create a stream in the dashboard: pick contacts as the data type, pick created, updated, deleted, or all changes, and set your HTTPS endpoint. From then on, Pathbound POSTs a JSON body with the full record, the source of the change, and the changed fields when a per-field diff is available. Changes are captured from every source: integration syncs, manual edits, form submissions, and the API.
Set a signing secret on the stream. Every delivery then carries X-Pathbound-Signature, an HMAC-SHA256 of the raw request body. Recompute it with your secret and compare in constant time—the docs include Node and Python examples. Treat the destination URL as public and verify every request.
A failed delivery (a non-2xx, a timeout, or a network error) retries up to 3 times with backoff at 1s, 10s, and 60s. After a long run of consecutive failures the stream pauses itself so we don’t hammer a dead endpoint; re-enable it from the dashboard once you’re healthy. Every delivery is logged there with response code, latency, body, and attempt count.
Deliveries typically leave within seconds of a change landing on the profile. When the events snippet records an event or a source updates a contact, the change is captured, coalesced with any other rapid changes to the same record, and delivered. What Streaming can’t do is beat the upstream tool: if a CRM only tells Pathbound about an edit on its next sync, the stream fires when we learn of it.
Yes. Event streams filter by event name and by URL substrings—only page views whose URL contains /pricing, for example. Contact and company streams filter by changed fields, so a stream fires only when lifecyclestage moves, and by source, so it fires only on changes that came from one origin. When no per-field diff is available the changed-field filter fails open, so you don’t silently miss updates.
Sign up, connect one CRM or drop the events snippet, and point your MCP client at mcp.pathbound.ai/mcp.