Skip to main content

Webhooks overview

Webhooks are how external systems notify Sprio that something happened, so Sprio can react — most commonly, placing an outbound call.

Contract

  • URL: https://api.voice-up.sprio.ai/api/webhooks/{provider}/{connectionId} — one URL per connection, provided when you set up the integration.
  • Method: POST, JSON body (shape depends on the source system — see Events).
  • Auth: a per-connection secret token in a custom header (see Authentication). LeadSquared and Zoho each carry this token differently on their side, but Sprio's validation is the same principle for both: a mismatched or missing token is rejected before any processing happens.
  • Response: Sprio always responds 200 OK quickly once the request is authenticated, before doing any real work — so your system doesn't see slow responses or timeouts as failures. Actual lead processing (dedup checks, owner-gate, call placement) happens asynchronously after the response is sent, via a bounded-concurrency queue — this is deliberate: a bulk lead import or mass reassignment can produce hundreds of events in a short window, and Sprio processes them without blocking the webhook response or overloading the database.
  • No retries from Sprio's side: if Sprio's async processing fails after the 200 was sent, the source system is not notified and does not resend. Failures are logged and surfaced on your Sprio dashboard's integration activity log — check there, not your CRM's own delivery log, to see the real outcome.

How each source keeps its registration alive

The two supported sources behave differently here, and it matters for troubleshooting "calls just stopped" reports:

SourceRegistration modelWhat can silently fail
LeadSquaredPersists once, no expiry — registered via their native Webhook.svc/Create APIAuto-disabled after 10 consecutive delivery failures (LeadSquared-side)
Zoho CRMA watch channel that expires (armed for 6 days, auto-renewed)Zoho has, in practice, reported a channel as active while silently delivering nothing — a periodic health check catches this independently of the channel's own reported status

If a client reports "leads stopped triggering calls" and nothing changed on the Sprio side, check the provider's delivery/channel health first — both failure modes above originate on the CRM side, not in Sprio's processing.

Supported sources today

SourceEventsDirectionStatus
LeadSquaredNew lead, owner reassignmentInboundLive
Zoho CRMLead created or updatedInboundLive

See Events for per-event payload shapes, and Testing for how to send test events safely.