In this webinar, PortaOne CEO Andriy Zhylenko and Product Officer Mike Kidik showed how customers can create integrations around PortaSwitch, attaching it to networks, back office applications, and anything you can imagine with minimum efforts and maximum efficiency using AI coding agents (also called “vibe coding”). The presentation covered enhancements of the PortaBilling API and included a live demo of vibe-coding (using Cursor.AI coding agent) a component that updates subscriber’s data in an external system when the subscriber is changed in PortaSwitch.
PortaBilling API 2.0: Modern Schema and Clear Naming, Built for AI Agents
The original PortaBilling API used attribute names and structures directly linked to the database schema; and they reflected telecom terminology from early 200x. It started in the era of SOAP and so it differs from the REST API, which is a de-facto standard these days and is known to any software developer (human or AI). So a developer or AI agent, writing a new application in 2025, had to overcome fair amount of confusion when trying to understand the meaning and purpose of individual API methods and attributes.
But most importantly when you find the right API methods to read the customer information, that customer object has references to other objects like customer class or reseller – but just as IDs (just like they are linked in the SQL database). To get information of those related objects, you need separate API calls for each one. So the application ends up sending multiple sequential API requests, which introduce delays on the front-end side and overloads the PortaBilling back-end; and sometimes you end up retrieving an object with 100+ attributes (e.g. “Reseller”) just to use one of them (e.g. “name”), which adds frustration when using a front-end app over a slow wireless network.
API 2.0 completely redesigns the schema following HTTP REST API best practices with modern terminology and clear attribute names that both developers and AI agents understand naturally. You can now request additional information from related objects in a single call – indicate that you need customer class data or reseller data along with the customer information.
You can now request that the server returns only specific attributes you need. Instead of downloading a 100-field customer object when you only need account status and balance, request just those two fields. Self-care portals load faster, mobile apps use less bandwidth, and your applications handle higher traffic with the same infrastructure.
Error handling has been reworked and error messages rewritten to make troubleshooting much easier when an API call produces an error.
Access 3rd Party Data Directly in UI (PortaBilling admin and self-care portal)
PortaBilling and CloudPBX Portal now can display data, stored in an external system (for instance a referral bonus system built in-house), as a part of the standard UI; so end-users can see everything without switching applications. This is done by creating data display widgets – mini web-pages that handle the data retrieval or modification and then are incorporated into the main UI. These widgets can be developed very quickly using in-house software engineering resources and AI coding tools. The webinar showed a referral tracking system embedded in customer management pages in PortaBilling administrator UI and an online store for buying VoIP phones and other telecom equipment integrated into the self-care portal.
This eliminates the need for customer service reps to juggle multiple browser tabs. Account information, referral commissions, and equipment orders appear in one unified view.
NSPS: Build Service Provisioning Without Learning PortaBilling API, Data Structures or Advanced Concepts
Traditional service provisioning required people to be very familiar with PortaBilling, including its structures, API, and so on, which severely limited the number of applications that could be written. The current External System Provisioning Framework (ESPF) system sends basic notifications like “A change operation on account with i_account=12345 has happened” and the provisioning application had to connect to PortaBilling’s API to retrieve the necessary data – i.e. what is the new product set, assigned to the account; what is the state of individual configuration settings (e.g. the list of call forwarding numbers), etc.
Besides the hurdles for a developer when writing the code – once deployed each provisioning application would retrieve the data independently. So if we have HSS, PCRF and IPTV platform connected to PortaBilling – there most likely will be 3 separate provisioning applications, one for each system. And when a new account has been created in PortaBilling – there will be three separate requests for the same account information in just a few seconds from each other, since each provisioning handler has to fetch the data.
NSPS complements the ESPF – it accepts the event information from PortaBilling (so no changes are required there and hence NSPS can be deployed alongside older PortaBilling versions!), but then maintains its own set of handlers (microservices doing the updates for a specific system such as HSS/HLR). Each handler gets its own separate queue – if one service experiences delays, it doesn’t affect the others.
The key innovation is NSPS’s built-in data retrieval component. Instead of forcing each handler to fetch data from PortaBilling independently, NSPS retrieves all necessary information once and delivers it as a complete JSON payload. This caches API requests intelligently – if multiple handlers need the same account information within seconds, PortaBilling only receives one request. And then NSPS delivers all required information as a single JSON payload to the micro-service, which implements the data changes in the external system. When an account changes in PortaBilling, your handler receives complete data needed for provisioning – and there is no need for its developer to open PortaBilling API.
For operations teams, NSPS includes error tracking and replay capabilities. When a provisioning event fails (e.g. the QoS profile has not been properly activated in PCRF, so we could not assign it to a SIM card), you can see exactly what went wrong and, after fixing the problem, “replay” those problematic events, so the changes to external systems are applie correctly.
Live Demo: Built Google Sheets Integration in 15 Minutes Using AI
During the webinar Andriy demonstrated building a provisioning application from scratch using AI coding agent live. The scenario was to create a connection between PortaSwitch and an external system with its own API. He used Google Sheets through APIs to more easily show that the new records are being added while screensharing, since there was no easy way to show real HSS provisioning results to webinar participants.
He configured a new NSPS handler through the web interface and fed PortaBilling’s API documentation to the AI coding agent. The AI generated code, though it needed some debugging. While the demonstration had some issues with data mapping that took about 10 to 15 minutes to resolve, it eventually worked and showed the subscriber data appearing in Google Sheets.
Poll Results: CRM Integration Tops Service Provider Priorities
We polled webinar participants about their integration needs. CRM systems are by far the most popular, and mobile core integration is still very relevant.
For CRM integration, typically you want to sync customer information. NSPS was created primarily to facilitate provisioning of accounts. For CRM, especially for customers, there’s usually a lot of conditional logic you need specific things for. If it turns out you have something fairly complex, you may be better off with PortaOne Workflows, which is a low-code platform.
Development Options: Pre-Built Python Adapter Available
NSPS uses HTTP REST to connect to a handler, so handlers can be written in any programming language – Python, Node.js, Java, or whatever your team uses. We have developed a sample handler (using Python and FastAPI framework) that implements an interface to HSS by World Telecom Labs. It has all the required code to process the requests from NSPS and can be deployed (as a Docker container) into a cloud environment such as Google Cloud or AWS. The code is provided as a sample that you can view, study, and adapt by adding your custom logic to work with the API of your system. It’s available publicly on our GitLab page.
For detailed implementation guidance, authentication requirements, event handling, and deployment examples, see the complete NSPS Connector Implementation Guide.
Special Offer for Early Adopters
Service providers starting with NSPS within the next month receive:
- Free business analyst consultation to discuss specific use cases and determine whether NSPS is the best fit, or if Workflows or something totally different works better.
- Dedicated NSPS instance in the cloud – your own, totally separated from others, so there are no concerns about data privacy or things happening with the data of your customers.
- No per-connector charges – whether you have three different workflows going to CRM or more, pricing is based on a base fee plus the number of events processed for high-volume scenarios.
- All cloud fees waived until the end of the year for early adopters willing to start in summer 2025, with permanent discounts on standard subscription fees afterward.
AI DataLink: Store Historical Data in the Cloud
PortaBilling deletes old historical data to maintain performance. We’re developing AI DataLink, a cloud-based platform where information is accumulated in parallel to your PortaSwitch. Records in PortaBilling get deleted because we don’t want to keep a lot of information, but the data in the cloud is accumulated, so we have very valuable history that would otherwise be lost.
The platform will work with modern AI analysis tools. We already have one customer using it in production for revenue analysis and customer insights. We hope to present results very soon.
Results: Faster Integration Development
NSPS enables people who have never seen PortaBilling interface or API in their life to create applications and microservices which will receive inbound requests and update the subscriber data in external systems; this enables maximum efficiency by using AI coding tools and agents.
The webinar demonstrated building a provisioning connector from scratch using cursor.AI coding agent. The core concept was proven – you can accomplish integration tasks without deep PortaBilling knowledge in less than 1 hour.
Contact your Customer Success Manager to evaluate whether NSPS, Workflows, or direct API integration best fits your specific provisioning requirements. We can discuss specific use cases and suggest the best approach.
Ready to cut your integration time from months to hours? Email us about your HSS provisioning, mobile core integration, or CRM synchronization project. We’ll schedule your free consultation and get your dedicated NSPS instance running within days – not months.
