How to send call recordings from your PBX to call analysis

Start by finding where your recordings actually live

Before anyone writes code, answer a plain question: where does a finished recording end up today, and how soon after the call? In most companies the answer is one of a few places. An on-premise PBX writes files to its own disk or a network share. A hosted PBX or contact-center platform keeps recordings in its own storage and exposes them through an export, a download link or an event when a recording is ready. Some sales teams record on the mobile phones they already carry, and those recordings never touch the PBX at all.

Each of these places suggests a different path into analysis, and it is normal to need more than one. Callens accepts calls three ways, which map onto those sources:

• An ingestion API that any dialer, PBX or contact-center platform can post to. The recording goes straight to storage, and submission is idempotent, so a retry never creates a second call.
• Browser upload for occasional files: MP3, M4A, AAC, WAV, WebM, OGG or FLAC, up to 200 MB and 60 minutes each.
• Enrolled recording phones, each with its own token that can be rotated or revoked.

What to send with each recording

The audio is only half of a call. The other half is the context your phone system already knows and the analysis cannot guess. If you send it at the start, every report later is sharper. If you do not, you will spend weeks matching calls to people by hand.

Send the recording itself as the phone system made it. Many PBXs compress recordings to save disk space, and some integrations convert them again on the way out. Every conversion costs detail, and the words that suffer first are the short, quiet ones a transcript depends on: a number said quickly, a «no» said softly. Send the file only once it is complete, too. A job that picks up a recording while the PBX is still writing it will send half a call, and half a call analyses cleanly into the wrong answer.

• Your own call ID. The identifier your PBX or platform gives the call. It lets you match results to your own records, and it is the natural idempotency key.
• Who the agent is. An extension number is not a person. Keep a mapping from extension or login to the named employee, and keep it current when people change desks or leave. Measures that belong to a named person are what make coaching possible.
• Direction and time. Inbound or outbound, and when the call started. A support queue and an outbound sales campaign should never be read as one population.
• Which team the call belongs to. Scorecards and benchmarks only mean something inside a department whose calls share a purpose.

Retries without duplicates

Networks fail, jobs crash and nightly exports run twice. A good integration assumes every submission may be sent more than once and makes that harmless. The rule is simple: when in doubt, resend the same call with the same key.

That only works if the key can be regenerated. A random value created at send time is lost when the job crashes; your PBX's own call ID is not. Build the key from something stable, such as the platform name plus its call ID, and the same recording will always produce the same key.

On the receiving side, Callens treats submission as idempotent, so a retry never creates a second call. That removes the most common source of noise in call analytics: the same conversation counted twice, scored twice and summarised twice, quietly distorting every average built on top of it.

Getting results back: signed webhooks, verified first

Analysis takes time, and the cleanest integrations do not sit and wait for it. They submit the call, move on, and let the result come back to them. Callens sends signed webhooks, HMAC-SHA256, on completion, when a call carries high risk, when a policy is breached or when a score is low.

Three habits keep this part reliable, whichever system sends the events:

• Verify the signature before you parse or trust the body. An unsigned or wrongly signed request is not a result, whatever it says.
• Answer quickly and do the real work afterwards. Acknowledge the delivery, put the event on your own queue, then update your CRM, ticket or dashboard.
• Treat the alert events as routing, not as reports. A policy breach can open a ticket for a supervisor; a low score can land in a coach's list. The full picture still lives on the call.

Keep access narrow from day one

Call recordings are some of the most sensitive data a company holds: customer names, account numbers, complaints, prices negotiated in confidence. The integration is a good moment to decide who and what can touch them.

Give each sending system its own credential and store it where your other production secrets live, not in a script on someone's laptop. For recording phones, one token per handset means a lost phone is one revocation, not a company-wide reset. Inside the product, access follows five roles, owner, admin, manager, reviewer and viewer, built from individual abilities, and recording access has its own audit trail.

If your team wants to ask questions of call data from AI tools it already uses, Callens offers an MCP server with read-only access. Read-only is the right default for that kind of connection: an assistant can look things up, but it cannot change what the calls say.

A rollout plan that does not surprise anyone

Do not route every line on day one. Start small, check what comes back, then widen. A sequence that works for most sales and support teams:

• Pick one team and one source, for example the inbound support queue on the main PBX.
• Send a week of past calls first, so managers see familiar conversations and can judge the output against what they remember.
• Check the agent mapping: every call should land on a named person, not an extension.
• Wire the webhook into one destination, verify signatures, and watch a few days of deliveries.
• Only then turn on live sending, and add the next team or source.