Your chatbot just collected a phone number at 11 PM from a visitor who asked about pricing and left their contacts for a callback. That lead is gold — but only if it reaches your sales process before morning. If leads sit in a dashboard nobody opens, or arrive as plain emails someone must retype into a CRM, half their value evaporates overnight.
The fix is a webhook: every time the chat captures a lead, Pravia delivers it straight to your system — Bitrix24, AmoCRM, HubSpot, a spreadsheet flow, or your own backend. This guide shows you both paths: no-code setup in about twenty minutes, and a custom endpoint if you have a developer. For the full technical reference, see the webhook integration page.
1What travels from the chat to your CRM
When a visitor shares their contacts — because the chat could not answer, or because they asked for a human callback — Pravia creates a lead and immediately sends one structured event to your webhook URL. The event is called lead.created, and it always carries the same fields: which chat and business it came from, the visitor's name, their contact details, what they asked about, and a unique key so you never save the same lead twice.
Think of it as a delivery note attached to every lead: who, how to reach them, what they want, and a serial number. Your job is to give Pravia an address to deliver these notes to, and to decide what happens at that address. That is the whole integration — everything below is just the details.
One thing to know upfront: each Pravia account holds one webhook subscription, and the delivery address must be a secure https address. Private internal addresses are blocked, because a cloud service cannot reach your office network — your endpoint must live on the public internet.
2Path A: no code, with n8n, Make, or Zapier
If you do not have a developer on hand, route leads through an automation platform first. You connect Pravia to the platform once, and the platform forwards each lead into Bitrix24 or any other CRM. No servers, no code, and you can watch every delivery in a visual log.
Most teams finish this in under half an hour, and the visual run history makes debugging painless: if a lead looks wrong in the CRM, you open the matching run and see exactly what arrived and how it was mapped.
3Pointing the flow at Bitrix24
Bitrix24 deserves its own section because so many small businesses run sales there. The platform accepts new leads through what it calls an incoming webhook: you create one in the Bitrix24 settings under developer tools, and Bitrix24 hands you a long URL that points at its lead-creation method. Paste that URL as the destination step of your automation scenario, and every chat lead becomes a Bitrix24 lead automatically.
The field mapping most teams use looks like this:
| Bitrix24 lead field | Fill it from the chat lead |
|---|---|
| Title | Chat lead from the website, plus the date |
| Name | The visitor name from the event |
| Phone or Email | The contact details from the event |
| Comments | What the visitor asked about, plus a link back to the chat |
Two practical tips. First, always include the visitor's original question in the comments — six months later, that sentence is what tells a salesperson whether this was a hot buyer or a casual browser. Second, decide who owns fresh leads in Bitrix24 before you switch the flow on: unassigned leads rot, whichever system created them. A simple distribution rule in Bitrix24, or notifications to the responsible manager, closes that gap.
If you use a different CRM, the pattern is identical — only the destination step changes. AmoCRM, HubSpot, and Pipedrive all have lead-creation steps in every major automation platform, and the incoming fields from Pravia stay the same.
4Path B: your own backend endpoint
If you have a developer and prefer full control — custom deduplication, enrichment, or routing logic — skip the middleman and point the Pravia webhook directly at your own endpoint. Your endpoint needs to do four things, and all four are simple.
First, accept POST requests with a JSON body at your URL and answer with HTTP 200 quickly. Pravia waits up to ten seconds for a response and retries failed deliveries, so a fast acknowledgement with slow processing afterwards is the right shape: save the event, respond, then do the heavy work.
Second, verify the signature on every request. Each delivery carries three headers: X-Pravia-Signature, X-Pravia-Timestamp, and X-Pravia-Event. The signature looks like t=unix-timestamp,v1=hex-code and is computed as HMAC-SHA256 of your secret over the timestamp, a dot, and the raw request body. Recompute it on your side and compare in constant time — never with a plain string comparison. Reject anything older than five minutes by the timestamp to block replayed requests. Full details are on the webhook integration page.
Third, deduplicate with the Idempotency-Key header. Retries mean you may legitimately receive the same lead twice — network hiccups happen. Store each key you have processed and skip repeats silently. The key for a real lead always looks like lead:lead-id, so it is trivially traceable back to the dashboard.
Fourth, treat the secret like a password. It is shown once in the dashboard, and anyone holding it can forge deliveries to your endpoint. Store it in environment configuration, never in source code, and rotate it from the dashboard the moment someone with access leaves the team — rotation is one click, and old signatures stop working immediately.
5Test before you trust it
However you built the receiving side, prove it works before announcing the integration to your sales team. Send the dashboard test event and confirm a test lead appears in the CRM with every field mapped — name in the name field, not in the comments; phone dialable, not truncated. Then capture one real lead yourself through the website widget, posing as a customer, and follow it all the way into the CRM.
If something fails, check the three usual suspects: the URL must be https and publicly reachable, the receiving scenario must be switched on (automation platforms love to leave scenarios in draft mode), and the signature check must use the raw, untouched request body — parsing and re-serializing JSON changes whitespace and breaks the signature. Fix those three and nearly every integration starts flowing.
The bottom line
A chatbot that collects contacts but cannot deliver them is a notebook nobody reads. One webhook turns it into a pipeline: the chat captures the lead at midnight, Bitrix24 or your CRM holds it by 12:01, and your salesperson calls back in the morning with full context. Set aside twenty minutes for the no-code path via the webhook integration guide, map the fields once, test twice — and never retype a lead from an email again. If you are still choosing a plan, the Starter tier at $9 already includes webhook delivery alongside its 3,000 monthly answers; see the pricing page or the setup reference in the integration docs.