What Webhooks Do (and Why You Need Them)
A webhook is an HTTP POST your system sends when an event happens. In TrafficValidator, that event is usually 'lead scored.' The scoring data goes straight to a URL you own. From there you can do anything: create a CRM contact, ping Slack, kick off a sequence, run custom logic.
Webhooks beat polling because you do not need a cron job hammering an API to ask if anything new happened. The moment the score lands, your system knows. For speed-to-lead workflows, that difference decides deals.
Setting Up Webhooks in TrafficValidator
In the project dashboard, Integrations → Webhooks → Add Webhook. Paste the destination URL, pick events (lead scored, verdict changed, threshold crossed), set a secret for payload verification.
TrafficValidator signs every payload with HMAC-SHA256 using your secret. Your receiver should verify the signature before doing anything. It takes about ten lines: hash the raw body, compare to the X-Signature header, reject on mismatch. That stops anyone else from forging webhook traffic to your endpoint.
Connecting to Zapier and Make
No-code works fine. In Zapier, 'Webhooks by Zapier' as the trigger, paste the URL into TrafficValidator, submit a test lead, Zapier picks it up and maps the fields for you.
Usable Zap patterns: score a lead → if score > 70, create HubSpot contact. Score a lead → if verdict = Definite Bot, add to suppression list. Score a lead → post a summary to #marketing-leads in Slack. Make (formerly Integromat) works the same way through its Webhook module.
Building Custom Webhook Handlers
If you have engineers, a handler is about thirty lines. An endpoint that accepts POST, verifies the HMAC, parses the JSON. The payload includes the score, verdict, every signal, and the original form fields.
Typical custom uses: write scored leads into your own database alongside user data, forward only legitimate leads to downstream CRM APIs while dropping the rest, pipe scoring data into a BI warehouse for analytics, or fire notifications based on team/region/campaign-specific thresholds.
Retry Logic and Delivery Guarantees
Failed deliveries retry with exponential backoff for up to 24 hours before the event is marked failed. Every attempt shows in the integration logs with response codes, and anything failed can be manually replayed.
Good practice on the receiver: return 200 fast, queue the work, process async. Do not block the 200 on downstream API calls. That keeps webhook latency low and avoids timeout-driven delivery failures during traffic spikes.