Destination
Attribi connects to a fixed list of CRMs and ad platforms, and your stack is not on it. The outbound webhook is the answer: give Attribi an HTTPS endpoint and it POSTs a signed JSON event when a lead is captured, when that lead is marked qualified, and when it closes won with revenue attached. It runs one way, from Attribi to you, which is worth knowing before you plan around it.
No credit card required · 5-minute setup
A lead.created event fires on conversion carrying the person’s full touchpoint history, then lead.qualified and lead.closed_won fire as the deal progresses, the second with the value and currency on it. Each is JSON over HTTPS to one endpoint you nominate.
Every request carries an HMAC-SHA256 signature computed over the timestamp and the body together, alongside the timestamp and the event name in their own headers. Signing them together is what stops a captured body being replayed at you later.
Attribi generates the signing secret rather than letting you type a passphrase, so it is never a reused password. Changing the destination URL keeps the same secret, so you do not have to redeploy your receiver, and rotating it is a separate deliberate click.
A button on the Connections page sends a real test event to your endpoint and shows you the status code it actually returned. You find out you responded 403 while you are still setting up, rather than from a gap in your data three weeks later.
Planned, not live today. Listed so you can see what this integration does not do yet, before you sign up.
A public API for querying your own attribution data, with keys you manage. Nothing like it exists today: data leaves Attribi only through the destinations we build, which are this webhook, the CRM connections, the Google Sheets export and CSV download.
Not yet available.
Attribi refuses anything that is not HTTPS, so no plain HTTP and no local address. Your endpoint should answer quickly and return a 2xx, because Attribi waits five seconds and treats anything slower as a failure. Acknowledge first and do your own work afterwards.
Save the URL on the Connections page and Attribi shows you a signing secret it generated. Copy it into your receiver and verify every request by recomputing the HMAC over the timestamp and the raw body, then comparing in constant time. Reject anything that does not match.
Use the test button and read the status code your endpoint returned. Once you see a 2xx, real events start arriving as leads convert and deals progress. Watch for the event name header to tell the three kinds apart, since they carry different fields.
Stages Attribi supports for Webhook.
Destination
Export attribution to Google Sheets: every new lead appends a row with five touchpoints, click IDs and referrers, into a sheet you pick from Drive.
CRM
HubSpot ad attribution in both directions: campaign data is written onto the contact your reps already read, and closed deal revenue is pulled back out.
Ad platform
Google Ads offline conversion tracking: send qualified leads and closed-won revenue from your CRM, so your account sees CRM-verified outcomes, not just form fills.
That event is lost. Attribi makes one delivery attempt per event with a five second timeout, records the failure on our side, and does not queue it for a retry or replay it later. There is no dead-letter queue for this path today. Build your receiver to accept quickly and do the real work asynchronously, and treat the webhook as a stream you may miss items from rather than a guaranteed ledger. If a deal must never be missed, the CRM connections are the more reliable route, because those read from your CRM on a schedule and re-read what they could not finish.
On the email address, which is the only field all three share. The lead.created event identifies the person by visitor id and does not carry a lead id, while lead.qualified and lead.closed_won carry the lead id and do not carry the visitor id. So a receiver that keys on lead id will never see the creation event for that lead, and one that keys on visitor id will never see the outcome. Key on email, and store both ids as you learn them.
Read the x-attribi-timestamp and x-attribi-signature headers, take the raw request body exactly as received before any JSON parsing, and compute an HMAC-SHA256 of the timestamp, a full stop, and the body, keyed with your signing secret. Hex encode it and compare against the header using a constant time comparison. Reject the request if it does not match, and reject it if the timestamp is far from your own clock, which is what makes replaying an old capture useless.
Not today. One workspace has one webhook endpoint and it receives all three event types, distinguished by the x-attribi-event header. If you need to fan out, route on that header inside your own receiver, which is also where any filtering belongs, since Attribi sends every event and offers no subscription options.
Not yet. There is no public REST API and no customer key management beyond the tracking ingest key, so the webhook is the push half of that need without the pull half. It is on the roadmap and it is not in the product. If what you want is a periodic snapshot rather than a live feed, the Google Sheets export and the CSV download from the reports are the two things that exist today.
Updated
Sign up and connect it from the Connections page.
Start FreeNo credit card · Free forever up to 1,000 visitors