Prerequisites
- Permission to manage webhooks in your workspace (admins have it).
- A destination URL on the public internet. If you don’t have a real one yet, webhook.site gives you a throwaway URL to test against.
- Any credentials your receiver requires (a username and password, a bearer token, or custom headers).
1. Open the Webhooks page
Open Webhooks under Integrations in the sidebar. You’ll see every webhook you’ve created, with its Event, URL, and whether it’s Active.
2. Pick the event and URL
Start in the Webhook section.
Here are some common picks.
- Lead Assigned pushes sold leads into your CRM.
- Lead Not Assigned pings your team when a lead finishes distribution unsold.
- Transaction Updated mirrors wallet activity into your accounting tools.
- Customer Created starts an onboarding sequence for each new customer.
3. Check the advanced settings
Advanced settings is collapsed, with a summary of the current choices (for example “No auth”, “POST”, “JSON”, ”10s timeout”, “No headers”). The defaults suit most CRMs. Expand it if your receiver needs something different.4. Shape the payload
In the Payload section, choose one of two options.- Default payload sends every field available for the event in a standard shape. For lead events, that includes the lead’s deliverable fields, and new fields are added automatically.
- Custom payload lets you choose fields, rename keys, add static values, or paste your own JSON shape.
contact.email, to nest it. The value can be static text, a field you insert from the picker, or a mix of both, and fields can take transformers to reformat them. Add row adds another. On lead events, Add all lead fields adds a single row that sends every deliverable field.
Two shortcuts save typing.
- Load default mapping replaces the rows with the default payload, so you can delete or rename from there.
- Paste JSON turns a sample payload, such as one from your receiver’s docs, into rows. Values that match an available field, like
{{ lead.email }}, become linked fields.
5. Choose the payload version
The Payload version section decides the shape of every request, with a card for Legacy and one for v1. A new webhook starts on v1, which wraps your payload in a fixed envelope. Here’s a trimmed Customer Created request.data, and the envelope tells your receiver what happened (type), when it happened (created_at), and which event it is (id, unique to each event). Pick Legacy only if your receiver already expects the original shape, where your mapping shapes the whole body.
The preview under the cards shows what your endpoint will receive, headers included. Its id and created_at are samples, since every event gets its own. If your mapping uses the {{ event }} or {{ tenant.* }} fields, an amber note names them, because they render empty on v1. Load default mapping adds event, tenant.id, and tenant.name rows, so delete those on a v1 webhook and use type and tenant_id from the envelope instead.
For everything v1 sends and how to switch an existing webhook, see Payload versions.
6. Create and test
Click Create & continue to testing. The webhook is active right away, and its edit page opens with a Testing section. Choose what to send.- Test with a real lead searches by ID, name, email, or phone and sends exactly what that lead would produce.
- Generate sample data fills every mapped field with realistic but fake values.
- Add test data manually lets you type in the values yourself.
- A 2xx means you’re wired up.
- A 4xx means you should check the URL and credentials.
- A 5xx means the receiver had a problem, so check its logs.
- A Timeout means the receiver is slow, so raise the Timeout in advanced settings.
7. Verify with a real event
Trigger the event for real and watch your receiver.- For Lead Created or Lead Assigned, send a lead (see Sending leads to Juiced).
- For Customer Created, create a customer.
- For Transaction Updated, add funds to a customer’s wallet (see Managing customer finances).
- Check the webhook is Active, not Paused.
- Check the URL is reachable from the public internet.
- Open the failed delivery and read the response. Juiced retries server errors (5xx) and connections that fail before the request is sent, up to 3 attempts in total, but not client errors (4xx). Fix the cause, then send it again.
Managing webhooks over time
- Pause or resume with the pause button on the webhook’s row, or with Pause webhook (or Enable webhook) on its deliveries page. The settings stay put while it’s paused.
- Edit with the edit button on the row, or with Edit on the deliveries page. Payload changes apply to the next delivery.
- Switch payload version in the Payload version section of the edit page. The preview shows the current payload next to the one after save, so check your receiver can read the new shape before you click Save changes.
- Replay a delivery by opening it and clicking Replay, or replay every failure from an outage at once with Bulk replay above the history. On v1, the original event goes out again with the same
id. See Replaying deliveries for how each kind works. - Delete with the delete button on the row, or with Delete on the edit page.
Customer webhooks
Customer webhooks are a separate flow that sends each lead assigned to one customer to that customer’s own endpoint. You can set one up from the customer’s Webhooks tab (see Customers), and customers can manage their own in their portal (see Webhooks in the customer portal). The form, payload options, testing, and deliveries work the same way as above.What happens next
With webhooks flowing, they cover a few common jobs.- For CRM sync, Lead Assigned webhooks are the usual way to get sold leads into Salesforce, HubSpot, or your own CRM.
- For finance, Transaction Updated webhooks mirror wallet activity into your accounting tools or data warehouse.
- For alerts, send Lead Not Assigned to a chat bot so your team hears when leads go unsold.