Webhooks

• Workspace webhooks fire on events across your whole workspace. You manage them under Integrations → Webhooks, and they’re what most of this page covers.
• Customer webhooks deliver each lead assigned to one customer to that customer’s own endpoint. See Customer webhooks.

​

The Webhooks page

​

Creating a webhook

• Event is what triggers the webhook (see Available events). Each webhook listens for one event.
• URL is where the request goes. It must be a public address, since internal and private addresses are rejected.
• Advanced settings (optional) cover Authentication (None, Basic Auth, or Bearer Token), Method (POST, PUT, or GET), Format (JSON or Form), Timeout (3 to 60 seconds, 10 by default), and extra Headers. The defaults suit most CRMs.
• Payload is either the Default payload or a Custom payload (see Payloads).
• Payload version starts on v1 for a new webhook and sets the shape of every request (see Payload versions).

​

Available events

​

Payloads

• Load default mapping fills the builder with the default payload, ready for you to trim or rename.
• Paste JSON takes a sample payload, such as one from your receiver’s docs, and turns it into rows. Values that match an available field become linked fields.

​

Available fields

• Lead events add Lead (lead.first_name, lead.email, lead.public_id, and the fields on your lead categories), Buyer (buyer.name, buyer.customer_public_id), Partner, Pricing (price, charged_amount, payout_amount), Assignment, Source, plus lead_type and lead_category
• Customer events add the customer’s details under customer., such as customer.name, customer.email, and customer.wallet_balance. Subscription events add subscription. fields, and User Attached To Customer adds user.name and user.email.
• Transaction Updated adds the customer under customer. and the transaction under transaction., such as transaction.amount and transaction.event

​

Lead fields

​

Public IDs

​

Payload versions

​

The v1 envelope

{
  "version": "v1",
  "id": "evt_01jbq7m4x2c9t5w8k3n6r0yzde",
  "type": "lead.assigned",
  "created_at": "2026-10-28T14:03:12Z",
  "tenant_id": "ten_01h8x2k4m6p8r0t2v4w6y8z0ab",
  "data": {
    "price": "$12.00",
    "charged_amount": "$9.00",
    "scope": "county",
    "buyer": {
      "id": "cus_01arz3ndektsv4rrffq69g5fav",
      "customer_public_id": "cus_01arz3ndektsv4rrffq69g5fav",
      "name": "Citrus Roofing"
    },
    "lead": {
      "id": "lead_01arz3ndektsv4rrffq69g5fav",
      "public_id": "lead_01arz3ndektsv4rrffq69g5fav",
      "source_id": "src_01hq3c5e7g9j1k3m5n7p9r1s3t",
      "first_name": "Ada",
      "email": "ada@example.com"
    },
    "lead_type": "Motivated Seller",
    "lead_category": "Home Sellers"
  }
}

​

Mappings on v1

• With the Default payload, data carries the full default payload for the event.
• With a Custom payload, your mapping shapes data and nothing else. You can’t rename or remove the envelope keys.
• The {{ event }} and {{ tenant.* }} fields render empty on v1, because the envelope’s type and tenant_id already carry them. On a workspace webhook, Load default mapping adds event, tenant.id, and tenant.name rows, so delete those on v1 and read the envelope instead.

​

Switching versions

• When the version you picked differs from the saved one, the preview shows the Current payload next to the payload After save, so you can compare the two before anything changes.
• The Headers list shows the headers the request carries, with credentials hidden.
• When v1 is picked, or you’re switching versions, a note above the payloads sums up what that means for this webhook. It turns amber when saving would change what your endpoint receives, or when your mapping uses {{ event }} or {{ tenant.* }} fields (it names them, since they’d render empty on v1).
• The preview’s id and created_at are samples. Every live event gets its own.

• Your payload now sits under data, inside the envelope.
• The root tenant block and event key are gone. Read tenant_id and type instead, and note that type uses names like lead.assigned where event sent names like LeadAssigned (LeadAssignedWebhook on customer webhooks).
• Numeric IDs become public ID strings like lead_… and cus_… (see Public IDs), so anything that stores or matches on the old numbers needs updating.
• Lead fields titled after an internal ID column, such as an old state_id field, aren’t sent. On Legacy they carry Juiced’s internal ID rather than the field’s own value. To send a value of your own, rename the field (see Adding fields to a lead category) and have your sources submit it under the new name.

​

Handling duplicates

​

Testing a webhook

• Test with a real lead searches your leads 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 the values yourself.

​

Deliveries

• Stats show Total deliveries, Success rate, Failed, Average duration, and Last delivery.
• Details list the Endpoint, Method, Format, and Trigger.
• Deliveries are split into Live and Tests, with Filters for the result and delivery date. Each row shows when it was sent, the lead (for lead events), the result with its response code and duration, and the delivery ID.

​

Replaying deliveries

• The original event goes out again when the webhook is on v1 and the delivery is a v1 delivery whose data Juiced kept. Your receiver gets the same id, created_at, type, and data as the first time, so it can spot the repeat, and a failed replay is retried like any other v1 delivery.
• A new event built from the lead’s current data goes out otherwise. That covers Legacy webhooks, v1 deliveries sent before replay existed, and deliveries sent while the webhook was on Legacy. It goes out as a single delivery with no scheduled retries and, on v1, a new id. This kind needs a lead behind the delivery, so a delivery for any other event can only be replayed as the original event.

• The dates are when each event was first sent, so replaying an outage finds every event from it however many times some have been replayed since.
• Only the latest delivery of each event is replayed, and only once it has finished. The status you pick applies to that latest delivery, so Failed skips an event whose last replay succeeded.
• Replays go out at 5 per second, so your receiver isn’t flooded.
• A bulk replay that matches more than 1,000 deliveries is refused, with the count, so you can narrow the dates or status.
• Each webhook runs one bulk replay at a time, and Bulk replay stays disabled until the current one finishes.

• Queueing means Juiced is still creating the replays.
• Sending means the replays are going out. On v1, retries can keep a bulk replay here for hours.
• Finished means every replay is done. The badge is Finished instead when some of them failed.
• Stalled means Juiced gave up creating the replays after an hour, so some were never queued. It doesn’t block a new bulk replay.

​

Reliability

• Automatic retries kick in when your endpoint returns a server error (5xx), or the connection fails before the request is sent. Juiced tries again, for up to 3 attempts in total. Client errors (4xx) and timeouts after the request was sent aren’t retried, so your receiver never gets the same event twice by accident.
• Timeouts follow the webhook’s Timeout setting, which is how long each request waits for a response.
• Isolation means each webhook is delivered on its own, so a failing endpoint doesn’t hold up the others.

​

Customer webhooks

​

Related guides