Skip to main content

Troubleshooting and Error Codes

Updated: Dec 3, 2025

Standard error response

When you receive an error, In the majority of cases the error shape will look like this:
Use the Calling API error codes list below to identify and resolve calling errors.

Calling logs

The Call Logs tab in WhatsApp Manager provides businesses and partners with a detailed, self-service view of call events to aid in call troubleshooting. The tab displays a table of recent call logs for your business phone numbers. Each call has a log, and each log can have multiple events which represent a Graph API request made by the business, or a webhook sent by Meta to the business. Each row represents a call, with different columns highlighted to provide information about each call log.

How to view call logs

Navigate to to WhatsApp Manager > Account tools > Phone numbers Select the desired phone number to view the call logs

Call Logs and Events

Calling error codes

SIP Errors

Also refer to SIP specific FAQ for additional troubleshooting info

Audio clipping issue and solution

When bridging the WhatsApp Consumer media leg via WebRTC to another media leg, such as SIP, it’s important to be aware of potential audio clipping issues and how to prevent them. A common symptom of this issue is that the WhatsApp consumer may miss approximately one second of audio from the business. For instance, if an IVR system is playing a sequence like “1-2-3,” the consumer might only hear “2” or “3.” The extent of audio loss varies based on the specific integration and the severity of the issue. The sequence diagram below illustrates this problem using an example where the WebRTC leg from the Cloud API is bridged with a SIP media leg. Depending on the SIP vendor and implementation, the media from the SIP User Agent might start playing at step 11, but it won’t reach the WhatsApp consumer until step 18.

Sequence diagram

Image ( Right click image and choose “Open in new tab” for enlarged image)

Components of the sequence diagram

WAConsumer is a WhatsApp user calling the business phone number using WhatsApp mobile app Meta is the Cloud API product MetaWebrtcEndpoint is the WebRTC agent on the Meta infrastructure BizIntegration is the webhook server receiving calls related webhooks and the app server with business logic to invoke Cloud API Graph APIs BizWebrtcEndpoint is the webrtc termination point as well as the SIP UAC typically in a media server on your side. BizSipEndpoint is the SIP User Agent (UA) often representing IVR or Business Agent.

Key points to note

Upon receiving the connect webhook (step 5 above), initialize your WebRTC agent, prepare the SDP answer, and make the Pre-accept Graph API call with the SDP answer. This pre-establishes the WebRTC connection in anticipation of an ‘accept/ok’ response from the SIP User Agent (UA). In most cases, the consumer’s call is answered, such as by an automated recording or IVR system. At step 11 above, wait for the ICE process to complete the creation of valid lists, indicating the near completion of ICE connection establishment (RFC reference). If the SIP UA rejects the call instead of returning a 200 OK, use the terminate Graph API to end the call. If the consumer connection is ready before the SIP connection, the consumer may experience a few milliseconds of silence, which is preferable to losing some initial audio from the business.

Root cause

When bridging two media legs, it’s crucial for the media server to synchronize their readiness to prevent audio clipping. In this scenario, the BizWebrtcEndpoint is allowing the SIP User Agent (UA) to transmit media significantly earlier than the WebRTC leg is prepared to receive it. As a result, packets are being dropped at the media server, leading to audio clipping issues.

Suggested solutions

Below is a high-level summary of alternative approaches to address audio clipping, intended to stimulate discussion and consideration. While each option has its drawbacks, you can assess their feasibility in the context of your specific requirements. Use SDES: Configure SDES on your business number instead of DTLS. We see a common reason for delayed setup of media leg between partner and Meta is DTLS handshake completion. Meta cannot complete DTLS handshake until it receives your SDP. You may not be able share your SDP with Meta until your internal endpoint responds to your with their SDP. Common DTLS implementations have a retry interval of 1s, 2s, 4s etc. After you send us SDP, we often see a ~3 second delay before we receive your DTLS client hello packet and this is when your internal endpoint is sending media but it is dropped. When you switch to SDES you can directly send SRTP after you send us your SDP. Delayed Audio Playback: Instruct the SIP User Agent (UA) to wait for an ACK from BizWebrtcEndpoint before playing audio. The ACK would be sent only after receiving a successful response from the Accept API, followed by an artificial delay. This approach ensures that the WebRTC connection is established before audio playback begins. Connection State-Based Delay: Direct the SIP UA to wait until the WebRTC connection state is ‘connected’ before playing audio. This method relies on the WebRTC connection being fully established before audio playback starts. Buffered Media Packets: Buffer SIP media packets and send them only after the WebRTC connection is established. This approach ensures that no audio packets are lost due to premature playback. Silence Insertion: Insert a brief period of silence into the IVR audio before the actual audio content. This method allows the WebRTC connection to establish itself while the IVR is playing silence, reducing the likelihood of audio clipping. Pre-accept: According to the RFC recommendation, a WebRTC agent, such as BizWebrtcEndpoint, should not transmit media until the ICE process is nearly complete. In our context, this means adopting an ‘optimistic accept’ strategy by invoking the pre-accept API call even before sending the SIP INVITE. According to SIP RFCs, a User Agent Client (UAC) should be prepared to receive media immediately after sending the INVITE. Therefore, it’s advisable to initiate the WebRTC connection setup process prior to sending the SIP INVITE. These solutions may have varying degrees of complexity and impact on your system. It’s essential to evaluate their feasibility and potential trade-offs in the context of your specific use case.

Support

For support concerning WhatsApp Business Calling API, choose the WaBiz: Calling API topic when opening a Direct Support ticket. Did you find this page helpful? Thumbs up icon Thumbs down icon ON THIS PAGE Standard error response Calling logs How to view call logs Call Logs and Events Calling error codes SIP Errors Media related issues Audio clipping issue and solution Sequence diagram Components of the sequence diagram Key points to note Root cause Suggested solutions Support