POST a signed JSON payload to it whenever a subscribed event fires — no polling required.
Webhooks are production-ready. All payloads are signed with HMAC-SHA256, retried with exponential backoff on failure, and protected against SSRF by blocking private IP ranges.
How It Works
- You register a webhook endpoint by calling
POST /v1/webhookswith a target URL and a list of events. - LeadLex returns a signing secret (shown once — store it securely).
- When a subscribed event occurs, LeadLex sends a
POSTrequest to your URL with a signed JSON body. - Your endpoint must respond with a
2xxstatus within 10 seconds. Otherwise the delivery is retried with exponential backoff.
Event Types
LeadLex fires 28 distinct event types across all core resources. Subscribe to as many (or as few) as you need.Contacts
contact.createdcontact.updatedcontact.deletedcontact.bulk_createdCompanies
company.createdcompany.updatedcompany.deletedDeals
deal.createddeal.updateddeal.deleteddeal.bulk_createddeal.bulk_updatedLists
list.createdlist.deletedlist.contacts_addedlist.contacts_removedCampaigns
campaign.createdcampaign.startedcampaign.pausedcampaign.deletedcampaign.step_createdcampaign.contacts_addedActivities & Tasks
activity.createdtask.createdtask.updatedtask.approvedtask.dismissedDelivery Headers
Every webhookPOST from LeadLex includes the following headers:
| Header | Description |
|---|---|
X-LeadLex-Signature | sha256=<hex> HMAC of the raw request body using your webhook’s signing secret. |
X-LeadLex-Timestamp | ISO 8601 timestamp of when the delivery was generated. Use to guard against replay attacks. |
X-LeadLex-Delivery-ID | Unique UUID for this delivery attempt. Use for idempotency in your handler. |
Content-Type | Always application/json. |
User-Agent | LeadLex-Webhook/1.0 |
Payload Structure
All webhook payloads share a common envelope:data object shape depends on the event type. For *.bulk_* events, data contains an array plus a count field.
Verifying Signatures
To verify, computeHMAC-SHA256(secret, raw_body) and compare it to the hex value in X-LeadLex-Signature (after stripping the sha256= prefix). Use a constant-time comparison to prevent timing attacks.
Retries & Delivery Guarantees
If your endpoint does not respond with2xx within 10 seconds, LeadLex retries the delivery with exponential backoff:
| Attempt | Delay |
|---|---|
| 1 | immediate |
| 2 | +30s |
| 3 | +2m |
| 4 | +10m |
| 5 | +1h |
| 6 | +6h |
failed and no further retries occur. All attempts — successful or not — are recorded in the webhook logs (accessible via GET /v1/webhooks/{id}/logs).
Deliveries are at-least-once. Use the
X-LeadLex-Delivery-ID header to deduplicate in your handler if exactly-once semantics matter.Security
Additional safeguards:- HTTPS required —
http://URLs are rejected at registration time. - Timeout — deliveries hard-timeout at 10 seconds to prevent slowloris attacks on LeadLex workers.
- Secret rotation — delete and recreate a webhook to rotate its signing secret.
- Replay protection — reject requests where
X-LeadLex-Timestampis older than 5 minutes.
Managing Webhooks
Use the API to register, update, and inspect webhooks:List webhooks
GET /v1/webhooksCreate webhook
POST /v1/webhooksUpdate webhook
PATCH /v1/webhooks/{id}Delete webhook
DELETE /v1/webhooks/{id}Delivery logs
GET /v1/webhooks/{id}/logs