From Reseller to Platform: PBXware Developer Portal

We talked to Dalibor B. about what problem the newest upgrade actually solves, what it changes about the sales conversation, and where partners should focus first.

Dalibor Bradvic

Product Owner

Launching alongside PBXware v8.1, the new Developer Portal at developers.bicomsystems.com is a bet that partners want to build, not just deploy.
Built by the engineers who develop PBXware, the portal provides technical documentation written by developers, for developers, making integrations easier to understand, implement, and maintain.

Dalibor Bradvic

What was actually broken before this existed?

Nothing was broken, but some things were slower and more expensive than they needed to be. A partner’s customer asks for their CRM to pop a screen when a call comes in, or wants call events feeding a custom dashboard.

Before the portal, that request either went back to Bicom Systems as a custom development ask, or the partner’s own developers had to reverse-engineer what was possible from scattered documentation and trial and error. Neither path is fast, and both add cost and risk to what should be a straightforward integration.

The portal doesn’t add a new capability to PBXware so much as it removes the friction between “PBXware can technically do this” and “a developer can actually build it this week.”

01-developer-portal-removing-friction

What does “first API call in minutes” really mean, concretely?

It means the gap between deciding to build something and seeing a real response from the platform is minutes, not a support ticket and a few days of back-and-forth.

Onboarding walks a developer through credential generation and scope configuration, and the interactive API reference lets them explore every endpoint with live code samples right in the browser, so they’re testing against the real API before they’ve written a line of production code.

That’s the difference between reading documentation and actually touching the thing you’re building against.

High angle view of business people working at call center

The Event Publisher gets mentioned alongside the API. Why does real-time matter enough to call out separately?

Because polling is a bad way to build anything that needs to feel live. If a partner wants a dashboard that shows call activity as it happens, or a workflow that triggers the moment a call ends, polling means either hammering the API on a tight interval or accepting real lag between the event and the reaction.

The Event Publisher streams call events as they happen, so an application can react immediately. That’s what makes live dashboards, screen pops, and automated workflows actually feel real-time instead of “refreshes every thirty seconds and hopes.”

03-real-time-event-publisher

Walk us through the ARI guides. Who is that actually for?

That’s for the partner whose customer has a call-routing or IVR need that’s genuinely custom, not “select from these five templates,” but bespoke logic specific to how that business actually operates.

ARI, the Asterisk REST Interface, is the foundation for building that kind of call control from scratch.

Step-by-step guides mean a partner’s technical team doesn’t need deep Asterisk internals expertise to get there; they need the guide and the willingness to build. That’s a meaningfully lower bar than what existed before.

Manager and executives with headsets using computers

How does a CRM connector fit alongside a full REST API? Isn’t the API enough?

The API is the general-purpose tool, and the CRM connector is the fast path for the single most common integration request partners get.

Tightening the loop between calls and customer records is something almost every business with a phone system eventually wants, and building that integration from raw API calls every single time, for every partner, for every customer, is wasted effort repeated across the whole partner base.

A dedicated connector means that specific, extremely common need doesn’t require custom engineering each time it comes up.

05-crm-connector-integration

How does this actually change a partner’s renewal conversation?

Every integration a customer builds on top of PBXware is a reason that customer doesn’t leave. Once a customer’s CRM talks to their phone system, or live transcription is feeding their workflow tools, ripping out PBXware means ripping out everything built on top of it too.

That’s a much harder conversation for a customer to have with themselves than “should we renew a phone system license.” The Developer Portal is what makes those integrations cheap enough to actually get built in the first place.

Partners go into renewal conversations with a concrete story of “here’s what you’ve built on this platform” instead of just “here’s what the platform does.”

Group of architects and business people working together and brainstorming

Which partners should invest here first, and which can wait?

Any partner with customers who’ve already asked for something custom, a CRM integration, a dashboard, anything bespoke, should start immediately, because that unmet demand is sitting there today.

Partners without technical teams of their own, or without customers asking for anything custom yet, can treat this as a forward-looking capability rather than an urgent one.

But it’s worth knowing it exists before a customer asks, rather than finding out reactively when they do.

07-partner-growth-opportunity

The AI integration guides stand out on this list. How do they connect to what customers are actually asking for?

Voice intelligence and live transcription are two of the most common “can it do this” questions partners get right now, because customers are hearing about AI everywhere else in their business and expect their phone system to keep up.

These guides mean a partner doesn’t have to figure out that integration from scratch. There’s a documented path to bringing real-time transcription and voice analytics into whatever they’re already delivering.

08-ai-voice-intelligence-guides

What’s the biggest mistake a partner’s dev team could make getting started?

Trying to build the most ambitious integration first instead of the smallest useful one.

The interactive reference and live code samples exist specifically so a team can validate an idea cheaply before committing engineering time to it, so use that.

Start with something narrow that proves the pattern, then expand, rather than scoping a six-month project against a platform you’re still learning.

09-start-with-small-useful-integration

Where does the portal go from here?

The goal is that it keeps pace with whatever PBXware ships next, meaning new capabilities show up in the API and the guides at the same time they show up in the product, not months later.

The portal is meant to be the living documentation of what’s actually possible on the platform, not a snapshot of what was possible on launch day.

Attractive business people in headsets are smiling while working with computer in modern office