I thought that API was internal only for Sangoma commercial things and not a public consumption API. What docs are you referring to that you are looking at?
I mean even if it is for commercial modules (looks like it is there to support Sangoma Connect), I should be able to tie into it as I am running that commercial module.
After some digging around I was able to connect and communicate with the api. The endpoint was just moved to “/rtapiws” vs the endpoint documented.
Switchvox is a way different pbx then FreePBX so those docs won’t match the best to FreePBX. Hence why it’s under switchvox and not FreePBX. @lgaetz would be able to clear up any confusion here.
We use Tenfold/Calli mixer but they are end of lifting asterisk support.
So a pop up on inbound call that makes it easy to input call data into CRMs.
Zulu might have worked but it looks like the chrome plug-ins were pulled.
So I built an electron app that captures data from the RT api to pop on screen with CRM context then use the CRM api to flesh out other call details.
As for switchvox and freepx being very different, I have no doubt. my guess is the RT apis bind to AMI very similarly so they are reused across the products.
I say similar because many of the calls are ‘switchvox.get.calllog’ and similarly namespaces with some freepbx specific calls mixed in. Basically if it is something that would come from asterisk, it looks like it is just reusing the switchvox api.
FreePBX has a CRM module with APIs for this exact use case. I would suggest using that versus the current way which may change without any notice as it’s a internal api for sangoma commercial things. You most likely are in license violation using something and reverse engineering how it works as this module is not open source so the things you are building using it also would most likely no be able to be OSS and again you are in no man’s land right now from a licensing perspective.
The CRM has a bit of what I need but not the full picture. Like I said, I use the CRM module to get the full picture but it lacks information in a timely context. The webhooks lack the ability to know which extension is ringing.
Now you do have a point in regards to it being an internal API and changing often, but my guess is it doesn’t as some of the methods are very old. But relying on that sounds much better than trying to write my own event stream parser for asterisk. Especially to start with but that might be in the cards.
It might be a license violation if I bothered get the module source and use that to write my own code that duplicates the rtapi (which I’m not doing).
As far as my use, it is perfectly legal for me to access an api running on hardware that I own.
I’m just using an undocumented api that is correctly licensed for my instance. It would be perfectly valid OSS as I own the rights to the code I write that is my own creation.
I’m not creating derivative works, reproducing their code in another language, or reverse engineering their code to see how it works (since as far as I’m aware, their code doesn’t do what mine does). If it does, I would happily buy it instead as that is much less work.