Skip to main content

Events

LeadSquared​

Full detail: Integration: LeadSquared.

Two separate webhooks are registered against the same connection URL — LeadSquared ties one webhook to exactly one WebhookEvent, so both are needed to cover real-world lead routing.

New lead (WebhookEvent=3)​

Triggered when a lead is created and the connection has auto-call new leads enabled. Fields are posted flat on the request body — the field names themselves are whatever your LeadSquared form/schema uses (see field detection for the list of variants Sprio checks).

Example payload shape:

{
  "ProspectID": "a1b2c3d4-...",
  "FirstName": "Test",
  "Phone": "+91XXXXXXXXXX",
  "EmailAddress": "test@example.com",
  "Source": "Website",
  "OwnerId": "owner-guid-here"
}

Owner reassignment (WebhookEvent=4)​

Triggered when a lead's owner changes — this is what fires in most real workflows (a lead being routed to an "AI Calling" account), not lead creation. Unlike the create event, the payload is wrapped:

{
  "Before": {
    "OwnerId": "old-owner-guid",
    "ProspectID": "a1b2c3d4-...",
    "Phone": "+91XXXXXXXXXX"
  },
  "After": {
    "OwnerId": "new-owner-guid",
    "ProspectID": "a1b2c3d4-...",
    "Phone": "+91XXXXXXXXXX",
    "FirstName": "Test"
  }
}

Sprio always reads the After state — this is the single most common integration mistake to check for if you're inspecting raw payloads yourself: a script or test harness that reads the top-level fields directly (instead of payload.After.*) will see nothing useful for this event type.

Registration-time validation ping​

Independent of either event above, LeadSquared sends a plain HEAD (then GET) request to the webhook URL at the moment it's registered, purely to confirm the URL resolves to something that answers 2xx. This carries no lead data and needs no auth — if you're watching access logs and see a HEAD/GET around connection setup time, that's expected, not an intrusion attempt.

Zoho CRM​

Full detail: Integration: Zoho CRM.

Lead created or updated​

Zoho's Notifications API watches Leads.create and Leads.edit — both matter, since a lead reassigned to your trigger owner after creation only fires the edit event, not create.

Unlike LeadSquared, Zoho's webhook body does not carry the lead's field values — only the changed record's ID(s), the module, the operation, and an echoed auth token:

{
  "token": "your-connection-token",
  "module": "Leads",
  "operation": "update",
  "ids": ["4876876000001234567", "4876876000001234568"]
}

Up to 50 IDs can arrive in a single notification (Zoho batches changes, e.g. a bulk reassignment). Sprio always fetches each lead's full record (GET /crm/v8/Leads/{id}) before processing — never trust or parse the notification body itself as containing lead data.

Delivery timing​

Zoho's own notification delivery is not instant and its exact latency isn't guaranteed the way a direct webhook is — if a lead update doesn't appear to trigger anything within a minute or two, check the connection's Activity tab before assuming something's broken; see Testing for how to isolate the cause.

note

Exact field-level payload schemas beyond the shapes shown above are source-system-specific and can vary by tenant configuration. Sprio does not require you to reshape anything — connect your existing LeadSquared webhook or Zoho watch-channel registration as-is.