So, I'm trying to interface my https://isptriage.com app with a PBX system, and like FusionPBX's overall functionality... it mentions API details but gives no information on the use of it, why? And does anyone have any details on this?
API
- Thread starter mortsmel
- Start date
Well you're getting fusionpbx free so why not pay for additional features. You're making money from it so why shouldn't the developers.
And if you want to provide a product to paying customers it's prudent to have expert support should you need it.
FS PBX (https://github.com/nemerald-voip/fspbx)
We are currently developing the API. It should be released soon. FS PBX is a forked FusionPBX with lots of additions targeting specifically external integrations
We are currently developing the API. It should be released soon. FS PBX is a forked FusionPBX with lots of additions targeting specifically external integrations
Within this forum there's a section for DjangoPBX which provides API and isn't tightly coupled with FusionPBX but uses the same core backend (FreeSwitch), or you could just interface directly with FreeSwitch.
If all you need is database access, the PostgreSQL database has a REST API. Takes only a moment to find using a search engine.
In another application where I'd interfaced directly with the database the software vendor had strong opinions against making any changes directly to the DB, stating taht doing so may have dire unintended consequences which would not be covered by their support (understandably so). One day I'll move up to the API support tier, but until then RPA and QA tools like PlayWright/Selenium/TestCafe/etc... seem like a (somewhat) reasonable workaround.
I was a bit surprised by the suggestion to modify the database directly, as this approach doesn’t take into account the additional steps required for the system to function as expected. Updating the database alone won’t reflect changes in the XML files used by FreeSWITCH, nor will it update the system cache. For changes to be fully applied, the process typically needs to trigger several background tasks as well.
Additionally, using a proper API provides an important layer of validation and security that you simply don’t get with direct database access. In today’s environment, where external systems can become compromised, it’s crucial to ensure all changes go through secure, validated API calls. This helps prevent unauthorized or unintended modifications and ensures the platform remains stable and secure.
That’s why a robust API isn’t just a convenience—it’s an essential part of making sure updates are applied consistently and safely across the system.
Additionally, using a proper API provides an important layer of validation and security that you simply don’t get with direct database access. In today’s environment, where external systems can become compromised, it’s crucial to ensure all changes go through secure, validated API calls. This helps prevent unauthorized or unintended modifications and ensures the platform remains stable and secure.
That’s why a robust API isn’t just a convenience—it’s an essential part of making sure updates are applied consistently and safely across the system.
@pbxgeek Replies to posts on this forum are for advertising. His interest at this point is driven by a desire to get as many people to leave FusionPBX as possible. His system is based on FusionPBX 5.1, and uses FusionPBX database, adding a different interface for some of the FusionPBX features, and additional features built by @pbxgeek. I tried to install his version. It took 2 or 3 times longer to install on FusionPBX, and it died on a dependency error. An error that I thought would be fixed as it had been reported on this forum a few weeks before.
FusionPBX design has been intentionally kept simple with fewer dependencies. I believe the KISS design principle is not only a good idea but also helps with stability.
My reply mentioned updating the database directly or through a PostgreSQL REST API. It was a suggestion not for my self-interest.
This is an exaggeration. If you don't realize what is happening, hear it's someone trying to steer you to a solution that benefits them. FusionPBX was built to work on a multi-server cluster. To do this, I made the XML generate on demand, and then to reduce server workload, it is saved to a file cache. FusionPBX uses the database with a file cache which can be deleted with a cronjob after a pre-defined time period of 5 to 15 minutes.
The file cache is in /var/cache/fusionpbx. This can be done with the find command and a cronjob.
Open cron with this command
Add this to clear the cache every 15 minutes. If you want a change to activate faster, set it to 5 minutes.
What configuration is not found in the cache?
There are at least three of these. Here is a link to one of them.
https://docs.postgrest.org/en/v13/
Proof of a good REST API comes with a track record of years of development, bug fixes, and longevity. What I offered as an open-source and free solution for a PostgreSQL REST API has all these qualifications.
FusionPBX design has been intentionally kept simple with fewer dependencies. I believe the KISS design principle is not only a good idea but also helps with stability.
My reply mentioned updating the database directly or through a PostgreSQL REST API. It was a suggestion not for my self-interest.
This is an exaggeration. If you don't realize what is happening, hear it's someone trying to steer you to a solution that benefits them. FusionPBX was built to work on a multi-server cluster. To do this, I made the XML generate on demand, and then to reduce server workload, it is saved to a file cache. FusionPBX uses the database with a file cache which can be deleted with a cronjob after a pre-defined time period of 5 to 15 minutes.
The file cache is in /var/cache/fusionpbx. This can be done with the find command and a cronjob.
Open cron with this command
Add this to clear the cache every 15 minutes. If you want a change to activate faster, set it to 5 minutes.
What configuration is not found in the cache?
- Changes to Advanced -> Variables
- Written to the vars.xml files
- Used only by the SIP profiles.
- This data rarely changes in a production system.
- /etc/fusionpbx/config.conf
- This is rarely changed on a production system
- /etc/freeswitch
- The files in here are rarely changed on a production system.
- When they are, then the server admin makes the changes on each server in the cluster.
- /usr/share/freeswitch/scripts
- Get their data from the database and dialplans that come from the database.
There are at least three of these. Here is a link to one of them.
https://docs.postgrest.org/en/v13/
Proof of a good REST API comes with a track record of years of development, bug fixes, and longevity. What I offered as an open-source and free solution for a PostgreSQL REST API has all these qualifications.
Last edited:
@markjcrane, I appreciate the work you’ve done to introduce caching in FusionPBX, which significantly optimizes the system by avoiding expensive XML regeneration directly from the database. This approach has undoubtedly made the system more efficient.
However, I noticed that the current recommendation is to clear the entire cache for even minor modifications. For example, if there are 1,000 domains and we make a simple name change to a single extension, it seems excessive to clear the cache for all 1,000 domains. Doing so can undermine the benefits of the caching system you worked hard to implement.
Additionally, it’s worth noting that these cache operations don’t address changes that require a FreeSWITCH reload, as you know. I just want to offer a word of caution: direct database modification isn’t the ideal approach. I’m a bit surprised to see this suggestion, especially given your deep understanding of the system’s architecture and optimization strategies.
A more targeted approach would better preserve performance and maintain system integrity.
However, I noticed that the current recommendation is to clear the entire cache for even minor modifications. For example, if there are 1,000 domains and we make a simple name change to a single extension, it seems excessive to clear the cache for all 1,000 domains. Doing so can undermine the benefits of the caching system you worked hard to implement.
Additionally, it’s worth noting that these cache operations don’t address changes that require a FreeSWITCH reload, as you know. I just want to offer a word of caution: direct database modification isn’t the ideal approach. I’m a bit surprised to see this suggestion, especially given your deep understanding of the system’s architecture and optimization strategies.
A more targeted approach would better preserve performance and maintain system integrity.
Thanks, this is possibly the nicest thing you have said to me in a long time.
I believe people can be creative and think about solutions. The file cache being cleared could be done on a different schedule per feature. The file cache has a prefix in the name. Also, if someone has the scale of 500 domains or higher, they can certainly find the means to get support if they need help with a better solution to fit their situation.
FreeSWITCH reloadxml is only needed when the XML in /etc/freeswitch is changed. However, because most items are handled with the database and the file cache, this is not a common activity. If someone does find a need to change the XML often for something specific, then I would write more code to build that XML on demand and bypass the need for reloadxml. Anthony, the creator of FreeSWITCH said he didn't build FreeSWITCH for reloadxml to be run all of the time FusionPBX design was changed to be more multi-server cluster friendly. This dramatically reduced the need for reloadxml.