The integration that breaks silently: why a webhook is not an integration
A script that pushes calls into your CRM works perfectly until the first network error. What a link between a PBX and your software actually needs, so you don't discover a month later that data is missing.
Most integrations between a phone system and a CRM look the same: at some point somebody wrote a script that takes the calls and pushes them onward. It worked. Everyone was happy.
Then, one Tuesday, the CRM server was restarted for an update. Three minutes. The script pushed into the void, got no answer, and moved on to the next call.
Nobody learned anything. A month later, somebody noticed the report did not add up.
What’s actually missing
Not the API. Not the data format. What’s missing is everything that only shows up when something goes wrong:
What happened to what didn’t arrive? A POST that got a 502 is information. If you do not write it down somewhere, it never happened. A serious integration has a delivery log: what went out, what your server answered, which code, and when the next attempt is due.
Who retries? And, more importantly, how. Immediate retries forever turn a three-minute outage into an attack on your own server. Retries have to back off, and after too many refusals pause on their own for a few minutes before resuming.
What is lost for good? There has to be an explicit answer, not silence. A row marked “Given up”, visible, that you can click on. Everything else gets recovered.
How do you recover? This is the heart of it: if push is your only channel, every minute of downtime is a permanent hole in your data. Which is why the first question about any integration is not “will you send me the calls?” but “can I ask you for what I lost?”.
The right order of channels
In our experience, integrations that survive look like this:
1. The history API is the foundation. You request the calls, for whatever period, with filters. It is boring and impresses nobody in a demo, but it is the only channel that cannot “lose” anything — the data sits there and you ask for it when you want. You use it for nightly syncs, for reports, and for repairing whatever another channel missed.
2. Real time is the layer on top. This is the one that impresses: the customer card opens by itself when they ring. Worth having, but built on the foundation, not instead of it.
3. The periodic file is for those without a developer. A CSV by email, on your schedule. It opens in Excel, it goes to accounting, it needs no code. This is not a second-class solution — it is the right solution for an entire category of businesses.
4. Recordings are a separate conversation. A metadata response is kilobytes; an audio one is megabytes, and fetching it occupies the customer’s PBX, not the vendor’s server. Any system that treats them identically either has not hit scale yet, or will throttle you without explaining why.
The trap we see most often
The address.
A service provider’s portal is almost always served behind protection built for browsers — bot checks, JavaScript challenges, rules that assume there is a human with a mouse on the other side. A browser passes through without noticing. A server-to-server integration never does.
Which is why the integration address comes from the documentation, not from the portal’s address bar. Ours is cool.pbxtools.ro, written literally, kept separate from the portal for exactly this reason.
If your vendor gives you the same hostname for both the interface and the API, ask them what happens when they turn on bot protection.
And the part nobody mentions: the invoice
Usage-based integration carries a risk vendors keep quiet about: a broken script on your side, stuck in a loop, can run up a night’s worth of consumption nobody expected.
The right answer is not “be careful”. It is a hard cap that stops serving, plus daily usage in plain sight, with the same figures the vendor sees. You do not find out at invoice time what you used.
What we do
PBX Connect is exactly those four channels, in that order, with the log, the stepped retry, the cap and usage in the open. API keys are shown once, revoked individually, and the right to read metadata is separate from the right to download audio — a reporting key never reaches conversation content.
For integrators running one PBX for several companies: each company has its own keys and sees only its own calls, enforced at the data layer rather than just in the interface.
It carries one flat monthly fee per company, with all four channels included — recording downloads among them — and a traffic allowance inside it. Not per extension, not per call. It runs on Asterisk-based systems — FreePBX, VitalPBX and centraletelefonice.ro PBX, multi-company included — and on bespoke platforms. FusionPBX is in progress. And if you run something else, tell us — we build on request, which is how every platform on the list got there.