3CX Rest API

[FSoftware]

Hello,

We are a software development company and would like to initiate calls in 3cx out of our software. Additionaly we’d like to get just-in-time information about the active calls for further processing.

As I understand, all this was possible with the Call Control API , which is not supported anymore.

I read here that there were plans for 3CX Rest API. Is it already implemented or any other possibility to do what we need?

 

[VoIPTools]

@e-gaulue I strongly urge you to search in these forums for previous discussions about accessing the Postgresql database directly. You will find that 3CX is strenuously opposed to anyone accessing the database directly and will flag your PBX as unsupported if they find out you are doing it.

 

[SweetAction]

(If you really want the 3CX DB without hitting the prod db, VOIPTools does have a "Exporter" that will replicate the DB into a SQL DB of your choice. It's part of their paid tools)

 

[OlegOLP]

There are third-party developments that are not authorized by 3CX.

 

[egaulue]

Of course if you write your SELECT request without taking care of scalability, you can hurt the DB. But, if 3CX forbid any access to it (for whatever reason), I will just use the log. I've checked it and I've got everything for my need. I'll request for the last connection involving a specific extension. It's just a grep pattern and I can even slice the log for the last few lines if too big. Having an oversized VM, I'm moreover pretty sure, the log files mainly stand in memory.

I think I will set all this week.

 

[wdiechmann]

Any progress on an API?

We are certainly not asking for much (just a ways to update user/extension status) something like

PATCH sipalco.3cx.dk/api/v1/extensions/11?status=available

 

[VoIPTools]

We can do it with our API.

 

[wdiechmann]

We can do it with our API.

your API?

Unless you are "inside" 3CX I cannot start to imagine how you can promote an API knowing that 3CX does not support an API.

Please, if you will indulge me, explain how you can promote an API without 3CX offering one

 

[Evolute IT]

your API?

Unless you are "inside" 3CX I cannot start to imagine how you can promote an API knowing that 3CX does not support an API.

Please, if you will indulge me, explain how you can promote an API without 3CX offering one

They built their own using 3CX Call Control which is an undocumented internal C# API to talk with the system.

 

[VoIPTools]

As mentioned by @ConceptsWeb, we wrote a "relay" application that runs on the 3CX server. This application connects to the 3CX Call Control API. The Relay then exposes our REST API that "relays" your request to the Call Control API, and returns the requested data, or performs the requested action.

Client Application <----> Relay REST web service <----> 3CX Call Control API

 

[wdiechmann]

They built their own using 3CX Call Control which is an undocumented internal C# API to talk with the system.

this raises even more questions

1 - how did they get hold on that c# API (I would certainly like to get hold on that too)
2 - this c# API is available on Windows only (if so - I'll pass)?
3 - how will we be able to "run" this relay application when using 3CX hosted solution?

 

[SnakeRiverWebDevelopment]

@VoIPTools is a former 3cx employee and has inside knowledge,

how will we be able to "run" this relay application when using 3CX hosted solution?

It will not work for hosted.

 

[wdiechmann]

As mentioned by @ConceptsWeb, we wrote a "relay" application that runs on the 3CX server. This application connects to the 3CX Call Control API. The Relay then exposes our REST API that "relays" your request to the Call Control API, and returns the requested data, or performs the requested action.

Client Application <----> Relay REST web service <----> 3CX Call Control API

@VoIPTools is a former 3cx employee and has inside knowledge,

It will not work for hosted.

that answers a lot of questions

 

[wdiechmann]

3CX is suspiciously absent from these threads on the API roadmap - what are the issues keeping 3CX from 'spilling' some API endpoints with minor implications on the product SLA?
I mean: if we were to fx set the extension status from another "product" I fail to see how this might be considered problematic?

 

[VoIPTools]

I need to clarify that our Relay WILL work even if your 3CX is hosted in the cloud. However, to @wdiechmann point, if you host your 3CX server with 3CX, they do not permit 3rd-party tools. But we host new customers every day and their 3CX is hosted in the cloud.

 

[wdiechmann]

I need to clarify that our Relay WILL work even if your 3CX is hosted in the cloud. However, to @wdiechmann point, if you host your 3CX server with 3CX, they do not permit 3rd-party tools. But we host new customers every day and their 3CX is hosted in the cloud.

I understand that, @VoIPTools, and we have done 3CX hosting in the past too. Does you pushing an 'API' (allow me to put API in ticks as I find it bordering "rules of engagement" ) somehow make 3CX postponing an "official" API?

(I'd really like to see someone from 3CX comment on this)

 

[VoIPTools]

3CX is suspiciously absent from these threads on the API roadmap - what are the issues keeping 3CX from 'spilling' some API endpoints with minor implications on the product SLA?
I mean: if we were to fx set the extension status from another "product" I fail to see how this might be considered problematic?

It is not clear (to me) what point you are trying to make, but let me say that nothing would make me happier than if 3CX were to release their own REST API to the public. We want to do things the "3CX way". If at some point in the future 3CX releases their own REST API, we will immediately switch over to their API. But, at least for now, that is not an option.

I will say, however, that there has been no news about a publicly available REST API from 3CX for quite some time. 3CX runs a tight ship and they are very focused on building a rock-solid, scalable, feature-rich PBX and perhaps they feel making a publicly accessible REST API would pull support and development resources away from their primary mission. I'm not going to start second-guessing Nick on his business decisions. I could only dream of being as successful as he has been. I'm 64 years old, and it is not likely that I will ever catch up to his level of success.

Our REST API was born of necessity. Originally our tools were installed directly on the 3CX server. But about 15 years ago 3CX asked us to move our tools off the 3CX server and install them on a separate server. They didn't want our tools consuming resources needed by 3CX. Given that the 3CX Call Control API only accepts requests from "localhost", the only way we could move our tools to another server was to create a REST API. This API makes it possible for our tools to communicate with the 3CX API. Making that API available to the public was an afterthought and only happened after considerable internal debate here at VoIPTools.

As it turns out, we don't get that many API support requests. We provide client DLLs (.Net) that obfuscate the complexities of communicating with 3CX and our APIs, and full Swagger documentation for our REST API, and a sample Visual Studio project. I assume these resources answer most questions.

 

[VoIPTools]

I understand that, @VoIPTools, and we have done 3CX hosting in the past too. Does you pushing an 'API' (allow me to put API in ticks as I find it bordering "rules of engagement" ) somehow make 3CX postponing an "official" API?

(I'd really like to see someone from 3CX comment on this)

I highly doubt our API has any impact on 3CX's decision whether to release their own REST API. Nick will always do what is best for the platform and 3CX customers -- period. And that is what he should do.

 

[wdiechmann]

It is not clear (to me) what point you are trying to make, but let me say that nothing would make me happier than if 3CX were to release their own REST API to the public. We want to do things the "3CX way". If at some point in the future 3CX releases their own REST API, we will immediately switch over to their API. But, at least for now, that is not an option.

I will say, however, that there has been no news about a publicly available REST API from 3CX for quite some time. 3CX runs a tight ship and they are very focused on building a rock-solid, scalable, feature-rich PBX and perhaps they feel making a publicly accessible REST API would pull support and development resources away from their primary mission. I'm not going to start second-guessing Nick on his business decisions. I could only dream of being as successful as he has been. I'm 64 years old, and it is not likely that I will ever catch up to his level of success.

Our REST API was born of necessity. Originally our tools were installed directly on the 3CX server. But about 15 years ago 3CX asked us to move our tools off the 3CX server and install them on a separate server. They didn't want our tools consuming resources needed by 3CX. Given that the 3CX Call Control API only accepts requests from "localhost", the only way we could move our tools to another server was to create a REST API. This API makes it possible for our tools to communicate with the 3CX API. Making that API available to the public was an afterthought and only happened after considerable internal debate here at VoIPTools.

As it turns out, we don't get that many API support requests. We provide client DLLs (.Net) that obfuscate the complexities of communicating with 3CX and our APIs, and full Swagger documentation for our REST API, and a sample Visual Studio project. I assume these resources answer most questions.

I am just confused, slightly irritated, and somewhat anxious - and if that spills into my questions please have my sincere apologies!

3CX is pushing a very competitive product - but we get an increasing number of requests for products/services that should 'drive' the extension, and possibly the call - and to that end we are building SaaS and other kinds of services that POSTs changes to PBX's.

We'd like to do the same with 3CX.

 

[SweetAction]

this raises even more questions

1 - how did they get hold on that c# API (I would certainly like to get hold on that too)
2 - this c# API is available on Windows only (if so - I'll pass)?

1. Parties interested have always been able to do some sleuthing to get the answers they need about the 3CX CallControl API. It's undocumented and unsupported, so you are on your own. I certainly wouldn't be raising any concerns about this on the forums - something about the squeaky wheel gets hit with a hammer?.
2. No, you can use it with Linux PBXes

3CX is suspiciously absent from these threads on the API roadmap - what are the issues keeping 3CX from 'spilling' some API endpoints with minor implications on the product SLA?

Software development being software development, you never commit to release dates or feature sets as they can change.

I mean: if we were to fx set the extension status from another "product" I fail to see how this might be considered problematic?

It's your PBX and you can do whatever you want however you want. But as the saying goes "2 can keep a secret if one of them is dead" - the second you invite 3CX into the PBX you also invite them to explain how 3rd party tools are not supported. Or in other words... run the tools you want, but don't complain to 3CX about problems unless you confirm it's not caused by the tools. I.e. replicate any issues you are having on a fresh install of 3CX before opening a case.

I am just confused, slightly irritated, and somewhat anxious - and if that spills into my questions please have my sincere apologies!

3CX is pushing a very competitive product - but we get an increasing number of requests for products/services that should 'drive' the extension, and possibly the call - and to that end we are building SaaS and other kinds of services that POSTs changes to PBX's.

We'd like to do the same with 3CX.

3CX will not officially bless a third party tool, but there are many who are doing this today - just keep in mind that any time you ask 3CX for support 3CX will direct you to have a vanilla install to rule out 3rd party tool issues.

 

[VoIPTools]

In that case, we can help. We have other software development companies using our APIs to build their integrations with 3CX.