Call Control API: How to check call status/ID for escalation logic (with a 30-minute delay)?

[Sonal-MA]

Hi everyone,

I am working on a project involving the Call Control API. The workflow is as follows:

1. A user creates a ticket in a ticketing system.
2. The system triggers an HTTP request to the callcontrol/makecall endpoint to call the engineer on duty.
3. The Challenge: If the first engineer does not answer, the system needs to escalate and call the next engineer—but only after a 30-minute delay.

What currently works:The ticketing system successfully initiates the call to the first engineer via the REST API.

Where I am stuck:I need a reliable way to check the call logs to determine whether the call was answered or missed. I tried using the Configuration API (ReportCallLogData / Pbx.GetCallLogData), but I cannot find a unique callId to filter or search the logs for that specific call.

My questions:

• Is there a way to retrieve a unique identifier (callId) when initiating a call via callcontrol/makecall so I can query its status later?
• Should I stick to the REST API for this verification, or is it better to switch to a WebSocket connection to listen for real-time call events (like no-answer/busy)?

Any insights or best practices on how to handle this escalation logic would be greatly appreciated!

Many thanks!

 

[Evolute IT]

We built this using CFDs. Much easier and simpler, with a backend DB.

@VoIPTools also has a great tool built for this.

I wouldn't bother reinventing the wheel.

 

[MichaelB_3CX]

For this workflow I would not rely on the call log or ReportCallLogData.

The makecall response may sometimes include a participant/result with callid, but it is not guaranteed in every makecall mode. For real-time escalation, the better approach is to use Web Call Control WebSocket events.

Recommended flow:

1. Connect to /callcontrol/ws.
2. Send POST /callcontrol/{dnnumber}/makecall.
3. Listen for participant events.
4. When an event references an entity like:

/callcontrol/{dnnumber}/participants/{id}

call:

GET /callcontrol/{dnnumber}/participants/{id}

5. The participant snapshot includes fields such as status, callid, legid, dn and party_dn.
6. Use status to decide the result:
- Connected = answered
- participant removed before Connected = missed/no-answer/failed
- Busy/Failed/Disconnected/Cancelled = failed

So yes, you can get a callid, but the reliable place to get it is from the live participant state, not from querying historical call logs after makecall. For escalation logic, WebSocket + participant snapshot is the recommended design.

 

[Sonal-MA]

For this workflow I would not rely on the call log or ReportCallLogData.

The makecall response may sometimes include a participant/result with callid, but it is not guaranteed in every makecall mode. For real-time escalation, the better approach is to use Web Call Control WebSocket events.

Recommended flow:

1. Connect to /callcontrol/ws.
2. Send POST /callcontrol/{dnnumber}/makecall.
3. Listen for participant events.
4. When an event references an entity like:

/callcontrol/{dnnumber}/participants/{id}

call:

GET /callcontrol/{dnnumber}/participants/{id}

5. The participant snapshot includes fields such as status, callid, legid, dn and party_dn.
6. Use status to decide the result:
- Connected = answered
- participant removed before Connected = missed/no-answer/failed
- Busy/Failed/Disconnected/Cancelled = failed

So yes, you can get a callid, but the reliable place to get it is from the live participant state, not from querying historical call logs after makecall. For escalation logic, WebSocket + participant snapshot is the recommended design.

Thank you so much! This is incredibly helpful and exactly the technical guidance I was looking for.

Your recommended workflow using the WebSocket connection (/callcontrol/ws) and checking the participant snapshots makes perfect sense.

I am going to implement this WebSocket approach right away. Thanks again for pointing me in the right direction!