Signed webhooks for lead intake workflows

The current integration layer sends HTTPS webhooks to Zapier Catch Hook, n8n Webhook, Make Custom Webhook, Pabbly Webhook, or a custom endpoint. A destination can then map the event into a CRM, spreadsheet, channel, field-service workflow, or internal API according to that external tool's capabilities and the customer's configuration.

A workflow recipe is not the same as a native integration. For example, sending a LeadGreeter event to Zapier and configuring a Jobber action is a customer-managed recipe; it should not be described as a direct product-maintained Jobber connector. The same boundary applies to CRM and notification recipes built through no-code tools or custom middleware.

Supported event names are lead.ready, lead.needs_review, lead.owner_notified, lead.booked, lead.lost, lead.opted_out, and lead.updated. Endpoints subscribe to selected events rather than receiving every internal change. That keeps downstream automation aligned with meaningful lead actions and reduces unnecessary exposure of raw operational traffic.

Payloads include an event identifier and creation time, basic business context, and a normalized lead record with source, status, customer contact fields, service, location, urgency, callback preference, notes, summary, review signals, and relevant timestamps. Raw transcripts, raw provider payloads, and raw AI request or response fields are outside this integration payload.

Each delivery includes x-leadgreeter-timestamp and x-leadgreeter-signature headers. The signature is an HMAC-SHA256 digest over the timestamp and raw request body, prefixed with sha256=. Verification should use the unmodified body, the endpoint secret, a timing-safe comparison, and a timestamp tolerance to reduce replay risk.

LeadGreeter encrypts the stored endpoint secret and decrypts it only when constructing a delivery. Customers must protect the corresponding secret in their receiving system, reject malformed or stale signatures, and rotate or replace destinations if a secret may be exposed. HTTPS is required for configured outbound delivery URLs.

A new event creates a pending delivery for each enabled, subscribed endpoint. Successful responses move the record to sent with the response status and delivered time. Unsuccessful responses or transport errors can move it to retrying with an attempt count and next-attempt time; terminal attempts become failed, while disabled destinations are recorded separately.

The dispatcher currently uses bounded attempts, request timeouts, HTTPS-only URL checks, and increasing retry delays capped at an hour. Delivery status helps an owner see whether LeadGreeter sent the event, but it does not prove the destination completed every downstream recipe step. Zapier, n8n, Make, Pabbly, middleware, and final applications have their own execution history.

Lead payloads can contain names, phone numbers, service needs, locations, notes, and summaries. The customer is responsible for choosing authorized destinations, limiting access, mapping only necessary fields, and complying with its own privacy and messaging obligations. Test endpoints should avoid forwarding sample or real lead data into uncontrolled tools.

Start with one narrow workflow recipe, such as adding a ready lead to an approved system or notifying a team channel, then test signatures, duplicate handling, retry behaviour, and failures. Use the eventId or delivery identifier for idempotency where appropriate. A custom endpoint should return an accurate HTTP status so delivery status reflects whether it accepted the payload.