How to send call recordings from your phone system for analysis

Where your recordings are today

Almost every phone system records calls. A cloud PBX keeps them per extension, a dialer keeps them per campaign, and a contact-center platform keeps them per queue. What these systems do not do is read them. Recording a call is not the same as knowing what happened on it.

To analyse calls, the recordings have to reach the system that reads them, reliably and without anyone copying files by hand. That is what a call recording API is for: your phone system, or a small script beside it, posts each finished call, and the analysis comes back without anyone checking a folder.

Three ways calls reach Callens

Callens accepts calls through three doors, and a team can use more than one.

• The ingestion API. Post a call from any dialer, PBX or contact-center platform. The recording goes straight to storage, and the call is submitted with its details.
• Browser upload. Drag a recording in as MP3, M4A, AAC, WAV, WebM, OGG or FLAC, up to 200 MB and 60 minutes. Useful for a pilot, or for a team without a phone system that can post.
• Enrolled handsets. Recording phones the team already carries can be enrolled, each with its own token that can be rotated or revoked, so one lost phone does not mean replacing every credential.

Why idempotency matters for call ingestion

Phone systems and integration scripts retry. A network drops mid-request, a worker restarts, a webhook from the PBX fires twice. If the receiving system treats each attempt as new, the same call is analysed twice, counted twice in every report and shows up twice in a manager's queue.

Callens submission is idempotent: a retry never creates a second call. Sending the same call again returns the call that already exists. That lets an integration follow the simplest rule there is, which is to resend when in doubt. The documentation at https://docs.callens.io explains how a call is recognised as the same call and which identifiers to send.

Getting results back: signed webhooks

An integration should not have to keep asking whether a call is ready. Callens sends results to your endpoint as webhooks, signed with HMAC-SHA256, so your system can confirm a delivery came from Callens before it parses the body.

Webhooks fire on completion, on high risk, on a policy breach and on a low score. That makes it straightforward to open a ticket when a support call breaches policy, notify a team lead when a call scores low, or write the finished analysis into your own records against the call identifier you sent.

Reading call data from AI tools

Ingestion gets calls in. Some teams also want to ask questions of the analysed calls from the AI tools they already use. Callens runs an MCP server that gives read-only access to call data from those tools. It reads, it does not change anything.

Inside the product, access follows the same roles as everywhere else: owner, admin, manager, reviewer and viewer, built from individual abilities. Tenant isolation is enforced at the database, not in application code, and recording access has its own audit trail.

What happens after a call arrives

Once a call is in, Callens reads it in Egyptian, Saudi or Emirati Arabic or English, attributes every measure to a named person, computes 22 conversation measures from word-level timings, and produces five judgments, what the customer wanted, who decides, the budget, the timeline and the outcome, each tied to the second it rests on. Any call exports as a PDF report and any filtered list exports as CSV.