Call Control API: makecall returns 200 with callId vs 202 with no callId — dual device registration?

[andrew.k]

We seem to be having inconsistent behaviour with the makecall endpoint of 3CX's callcontrol API. Sometimes it returns a 200 with a call ID and sometimes a 202 with no call ID. We're evaluating a solution for an integration using the makecall endpoint but would like to be certain about 3CX's behaviour in regards to this endpoint. Since 3CX does not support their API's does anyone else have experience with the makecall endpoint and potentially know why we sometimes get 202's and not 200's? Our hypothesis is it has something to do with multiple device's or multiple sessions for the same user but the behaviour does not seem to be consistent

 

[vipin.rathore@thetelephon]

From what we've observed, the behavior may be related to the registration state of the extension being used with the makeCall endpoint.


For the makeCall(extension, number) request to complete successfully, the extension should be actively registered on at least one client (Web Client, Desktop App, Mobile App, or IP Phone). We've seen cases where a user appears to be logged in, but the extension is not actually registered at that moment, which can lead to inconsistent call initiation behavior.


It may be worth comparing the registration status of the extension when you receive a 200 response versus when you receive a 202 response. In particular, check whether the extension is shown as available/registered (green) in 3CX and whether the user has an active device or client connected.


If you're using the Web Client, also verify that the required browser permissions (microphone, notifications, location where applicable) are granted and that the client is fully connected.


As a troubleshooting step, try testing with an extension that has a single actively registered device and compare the results. This may help determine whether the response difference is related to extension registration or client availability rather than the API request itself.


Out of curiosity, have you noticed whether the 202 responses occur when the extension is not registered on any active client?

 

[nikolascx]

@vipin.rathore@thetelephon Thanks for your help on this one. You could be in the right direction.

The main point is this: 202 Accepted does not necessarily mean failure. It usually means the makecall request was accepted but the PBX has not immediately produced/returned a call object/call ID at the time of the HTTP response.
200 OK with callId means the call object was created immediately enough to be returned.

The difference between the two responses is likely related to the state of the extension/device at the moment the makecall request is processed.

– A 200 OK with a callId means the PBX was able to create the call object immediately and return its ID in the response.
– A 202 Accepted means the request was accepted for processing, but a call object was not available to return synchronously at that point, so no callId is included.

This can happen when the extension’s currently usable endpoint is not clear or not immediately available, for example if the extension is not actively registered, the selected/active device is disconnected, or there are multiple registered devices/sessions and the PBX has to resolve where to originate the call from.

I would suggest testing the same request under these conditions:

1. Extension registered on only one device/client.
2. Extension not registered anywhere.
3. Extension registered on multiple devices.
4. Web Client/Desktop App open and actively connected versus closed/disconnected.

Also compare the extension’s presence/registration state in 3CX at the exact time you receive 200 versus 202. Essentially the same things that VIPIN explained.

So yes, multiple devices may be part of the explanation, but I would not treat dual registration alone as the root cause. The more important factor is whether the PBX has an immediately available endpoint from which it can originate the makecall request.

Also, I would not promise that 202 is caused only by missing registration. It can be other reasons. I’d also avoid saying “green presence” equals registration with certainty, because presence and SIP/client registration are related but not always the same thing.

Let us know what you get from these tests.

One quick gentle clarification about the comment that we do not support our API - the way you put it is not entirely fair.
We only support bug reports on our API. So if you have a bug and you make a sample application that proves the bug, we will support it and fix it. Anything that makes us dig into 3rd party code to troubleshoot, we cannot support.

I'm sure you will get this working. Let us know how the tests proceed for you. God bless

 

[andrew.k]

Thanks everyone for the detailed responses — this has been really helpful in understanding the behaviour.

To add more context about what we're actually trying to achieve: our integration initiates outbound calls via makecall and then retrieves the call recording afterwards to send to a third-party system. The callId returned in the 200 response is what we use to look up and associate the recording to the originating request.

The problem we're running into is that when we receive a 202 with no callId, we have no reliable way to correlate the recording back to the call we initiated. The recording exists in 3CX — we just can't identify which one belongs to us.

We're planning to switch to the device-specific endpoint (POST /callcontrol/{dn}/devices/{deviceid}/makecall) as suggested, but based on your responses it sounds like even that endpoint can return a 202 in some cases.

So our specific question is: if the device-specific makecall returns a 202 with no callId, what is the recommended way to eventually obtain the callId so we can retrieve the correct recording? Specifically:

1. Is subscribing to WebSocket events the most reliable path to get the callId after a 202? And if so, which event carries the callId once the participant is fully created?
2. As a fallback, can we poll GET /callcontrol/{dn}/participants and match by timestamp + destination to find the right participant and extract the callId that way?
3. Is there any other identifier returned in the 202 response body that can be used to correlate the call later — even if the callId itself isn't available yet?

Essentially we need a guaranteed path from "call initiated" to "recording retrieved" regardless of whether we get a 200 or 202. Any experience with this specific scenario would be really appreciated.

 

[nikolascx]

Hi Andrew,

Yes, multiple devices or sessions for the same DN could explain this behaviour, but it is not the only possible reason.
Can you confirm that you do not have multiple sessions? In my previous answer I asked you for a block of tests. Can you give me a confirmation on those questions please?

The DN-level endpoint:

POST /callcontrol/{dn}/makecall

can return <span>202 Accepted</span> when the request has been accepted but the call initiation result is not available synchronously yet. In that case, the application should monitor the DN participant state to discover the call that was created.

If the DN has only one registered device, the call is normally initiated from that device. If the DN has multiple appearances/registered devices, the legacy MakeCall service is used, which can make the result less deterministic from the initial HTTP response.

So let's assume that you have only one device registered, a <span>202</span> response is still not necessarily an error. It means the request was accepted, but you should rely on participant state / WebSocket events to track the call result.

For integrations where you need more deterministic behaviour, the better approach is to retrieve the DN devices first and then use the device-specific endpoint:

<span>POST /callcontrol/{dn}/devices/{deviceid}/makecall</span>

That way the originating device is explicit, and the integration does not need to rely as much on the backward-compatible DN-level MakeCall behaviour.

Hope this helps. God bless