CRM & webhooks

Lead push

Your CRM calls POST /api/v1/leads (or /events). Ondial does not pull CRM contacts for the Public API path unless you also use dashboard CRM integrations separately. On accept, Ondial fires a lead webhook (when subscribed):

Ingest result	Event	`data.action`
New contact	`outbound.lead.created`	`created`
Upsert (no redial)	`outbound.lead.updated`	`updated`
Finished contact + `requeue: true`	`outbound.lead.updated`	`requeued`

Finished contacts need requeue: true (otherwise 422 requeue_required). Each successful requeue arms a new dial and later emits a new set of call webhooks under a new callId.

Inbound CRM read

After wiring Sheets / Zoho / Custom API on an inbound agent (dashboard or HMS inbound APIs), call
POST /api/v1/inbound-agents/{id}/crm/lookup to look up order/person data with your API key (no live call). Hospital platforms that own doctors and booking: Healthcare HMS integration. Use your branchId / doctorId and HTTPS webhook - not sample placeholder IDs.

Event catalog

Register an HTTPS URL via POST /api/v1/webhooks or API Access → Notifications. Ondial posts signed events: Outbound

outbound.lead.created
outbound.lead.updated (action: updated | requeued)
call.outbound.status (legacy: call.status)
call.outbound.billed
call.outbound.analysis (legacy: call.analysis, analytics.call)
whatsapp.outbound.status (legacy: whatsapp.status)
email.outbound.status (legacy: email.status)
followup.scheduled
contact.cancelled

Inbound

call.inbound.started
call.inbound.completed (usually billingStatus: pending)
call.inbound.billed
call.inbound.analysis
whatsapp.inbound.received
inbound.lead.created

Billing

credits.usage - wallet ledger push after a successful deduct (paired with call.*.billed)

Outbound dial lifecycle (typical order)

For one dial attempt (including after requeue), CRM listeners usually see:

outbound.lead.created or outbound.lead.updated - at ingest / requeue time
After hangup / charge - call.outbound.billed and credits.usage
call.outbound.status - e.g. completed
call.outbound.analysis - when post-call AI analysis is ready (may lag a few seconds)

Upsert by callId (or conversationId) per dial. Do not assume one contact = one call forever - requeues create new call rows and new webhook sets.

Matching events to your CRM leads

Send your own lead id as leadId when you push the lead (see Push leads). Ondial then includes the same leadId in:

Event	Where
`outbound.lead.created`, `outbound.lead.updated`	`data.leadId`
`call.outbound.status`	`data.leadId`
`call.outbound.billed`	`data.leadId`
`call.outbound.analysis`	`data.leadId`

leadId is returned exactly as you sent it (177 stays a number). It is left out when the lead was sent without one, so keep using contactId as a fallback.

Callback requests in `call.outbound.analysis`

When the lead asks to be called back, data.nextAction has type: "Callback" plus a resolved date and time, so your CRM doesn’t have to interpret phrases like “tomorrow afternoon”:

"nextAction": {
  "type": "Callback",
  "action": "Call the parent back tomorrow afternoon as requested.",
  "date": "2026-10-14",
  "time": "15:00",
  "priority": "Medium"
}

Field	Format
`date`	`YYYY-MM-DD` in the campaign timezone. `null` when the lead gave no specific day.
`time`	`HH:mm` (24h) in the campaign timezone when the lead gave a specific time. Otherwise the time slot as text, e.g. `"Afternoon"`.

All other calls keep the usual nextAction shape (type, action, priority) with no date or time.

Delivery, retries, idempotency

Envelope:

{
  "eventType": "call.outbound.status",
  "occurredAt": "2026-09-09T07:37:23.000Z",
  "data": {
    "callId": "call_9f3c2a1b",
    "contactId": "66f0a1b2c3d4e5f678901234",
    "leadId": 177,
    "status": "completed"
  }
}

Headers:

X-Ondial-Signature - HMAC-SHA256 hex of the raw body with your webhook secret
X-Ondial-Event - event type
X-Ondial-Idempotency-Key - stable delivery key (also used server-side to avoid double POSTs)

Rules:

Same logical event is delivered once per webhook URL when the prior delivery succeeded.
Call events key on event + callId (plus status / bill identity). Each new dial → new callId → new deliveries.
Lead update/requeue keys on event + contact + action + scheduledAt, so each requeue: true can fire again.
Failed POSTs (4xx/5xx / network) retry up to 3 times with short backoff; a later successful retry updates the same delivery log.
Return 2xx quickly. Rate limits (429) or tunnel errors (502) on your side look like “missing” events even when Ondial sent them.

Inbound credits are async (session end ≠ bill). Prefer *.billed / credits.usage plus poll GET /api/v1/credits/transactions. See Usage & call analytics. Dashboard CRM OAuth (HubSpot, Shopify, etc.) remains a separate product path - not part of public campaign CRUD.

Get started

Send leads (outbound)

Answer calls (inbound)

Integrations

Concepts

Go live

Lead push

Inbound CRM read

Event catalog

Outbound dial lifecycle (typical order)

Matching events to your CRM leads

Callback requests in `call.outbound.analysis`

Delivery, retries, idempotency

​Lead push

​Inbound CRM read

​Event catalog

​Outbound dial lifecycle (typical order)

​Matching events to your CRM leads

​Callback requests in call.outbound.analysis

​Delivery, retries, idempotency

Lead push

Inbound CRM read

Event catalog

Outbound dial lifecycle (typical order)

Matching events to your CRM leads

Callback requests in `call.outbound.analysis`

Delivery, retries, idempotency