Reporting & webhooks

The moment a call ends, its transcript, summary, and outcome land on your server — and whatever you'd rather fetch on your own schedule, the API holds. Nothing about a call stays locked inside OnCore.

What it is#

When a call finishes, OnCore sends your server a report with everything about it: the full transcript, an AI-written summary, how the call was categorised, whether a hand-off to your team was answered, and why the call ended. A companion event fires when each call starts, so your systems know who is on the line before the call is over. Messaging conversations get the same start and end reports, and everything is also available to pull from the REST API whenever you want it.

What you can do with it#

• Log every call in your CRM automatically — the transcript, summary, and outcome arrive on your server the moment a call ends, ready to attach to the customer record with no polling and no manual notes.
• Prepare while the caller is still talking — the call-start event identifies the caller and the call, so you can look them up and open a record before the end-of-call report lands.
• Act on missed hand-offs — every report says whether a transferred call was answered, so you can alert your team the moment a caller went unserved.
• Measure what callers ask about — each call carries a summary and category labels you define, so your reporting shows call mix and outcomes without anyone listening back to calls.
• Backfill and audit on your schedule — pull filtered call history, per-assistant summaries, or a bulk export from the API at any time, independent of webhook delivery.

How to set it up#

Everything runs over OnCore's REST API and plain HTTPS webhooks — no SDK required. Point deliveries at your server by setting a webhook URL on the assistant; each delivery carries a secret header your server checks, as covered in the webhooks overview. The payloads are documented per event: the end-of-call report when a call ends, the assistant request when a call starts (your response can even customise the call that is starting), and the end-of-conversation report for messaging channels. To pull instead of receive, read call history with the calls API and messaging history with the conversations API.

Limits & FAQ#

• Call and conversation deliveries are not retried. If your endpoint is down or returns an error, that report is not redelivered — respond quickly with a success status, process asynchronously, and backfill any gap from the calls API, where the record is always available.
• Verify every delivery. Each webhook carries your client server secret in a header; reject requests that don't match — see the webhooks overview.
• Bulk export returns lean rows. The export endpoint returns up to 10,000 calls without transcripts or recording links — fetch individual calls for full depth.
• The calls API is read-only. Calls are created when customers ring your numbers; the API and webhooks report on them.

What exactly is in the end-of-call report? Call and assistant identifiers, the caller's number, the full transcript and message log, the summary, category labels, the transfer outcome, timings, why the call ended, and the recording link when recording is on — the full field list is on the end-of-call report page.

How do we know if a transfer was answered? The report includes the transfer outcome: which hand-off rule triggered and whether the destination picked up (voicemail counts as answered) — so missed hand-offs are flagged on every call. See the end-of-call report.

What happens if our endpoint is down when a call ends? That delivery is lost — there is no retry for call and conversation events. Poll the calls API for the window you missed; every call record, including transcript and summary, stays available there.

Do chat and SMS conversations report too? Yes. Messaging conversations send their own start and end events, keyed by a conversation identifier instead of a call identifier, with transcript, summary, and analysis — see the end-of-conversation report.