Lead payloads
Lead events carry the LeadFatPayload. The entity arrives inside the standard webhook envelope under data.object, with object set to lead.
Leads map to the Customer model. A lead's id carries a cus_ prefix even though object is "lead". This is intentional - a lead is a customer record in an early pipeline stage. See the reconciliation note below before writing any code that keys off the ID prefix.
Base fields
Every lead payload shares the base event fields, sourced from BaseEventPayload.
| Field | Type | Nullable | Notes |
|---|---|---|---|
| event_id | string | No | Stable UUID, prefixed evt_ in the envelope |
| id | string | No | Raw entity UUID - carries the cus_ prefix (see reconciliation note) |
| workspace_id | string | No | Raw workspace UUID |
| created_at | datetime | Yes | Entity creation timestamp |
Lead fields
These fields extend the base set for lead payloads.
| Field | Type | Nullable | Notes |
|---|---|---|---|
| name | string | No | Lead's display name |
| string | No | Lead's email address | |
| phone | string | Yes | May be an empty string when not provided |
| description | string | Yes | Free-text note - may be an empty string |
| stage | string | No | Pipeline stage, e.g. lead |
| setter_id | string | Yes | UUID of the assigned setter |
| closer_id | string | Yes | UUID of the assigned closer |
| setter | object | Yes | team_member (Variant B) or null |
| closer | object | Yes | team_member (Variant B) or null |
| crm | object | No | { source, source_id, synced } |
| providers | array | No | Array of { provider, id } external references |
| is_active | boolean | No | Whether the lead is active |
| updated_at | datetime | No | Last update timestamp |
The setter and closer objects use the Variant B team_member shape - { ..., department, is_active } with no user_id. See Nested objects for the full team_member shapes and how the variants differ.
Reconciliation note - the cus_ prefix
Lead is not a standalone entity in PayDai's data model - it is the Customer model surfaced at an early pipeline stage. As a result:
- The lead
idis prefixedcus_(e.g.cus_b2409114-...), the Customer prefix - not alead_prefix. - The payload's
objectfield is still"lead".
If you route or store webhooks by ID prefix, treat cus_ IDs arriving on lead.* events as leads. Match on event_type or object, not on the prefix alone.
Event types
lead.created
A new lead entered the pipeline. Carries the full field set. In the real example, crm.source is null and crm.synced is false - the lead originated in PayDai rather than syncing from an external CRM.
lead.created (real payload)
Code
lead.updated
A lead's fields changed. Same shape as lead.created. In the real example, the lead has synced to an external CRM - crm becomes { "source": "gohighlevel", "source_id": "SQH6L2RCqM1NvscXHYGi", "synced": true }, and the setter carries roles: ["manager", "setter"]. Compare against the lead.created example above: the key difference is the populated crm block once a sync has occurred.
lead.deleted
A lead was removed. The payload carries the lead's last known state under data.object. Treat the arrival of this event as the signal to remove the lead from your store; do not rely on field values to detect deletion.
