Welcome!
What did you do?
This appears to be a regression of a previously fixed bug.
When sending a message to a valid Brazilian WhatsApp number that does not use the ninth digit (e.g., some landline-like numbers in DD 75 starting with 8), the Evolution API incorrectly forces the addition of a '9' after the area code.
This causes the message to be sent to a JID that is not a registered WhatsApp user. From the API's perspective, the message is sent (status: PENDING), but it is never delivered to the intended recipient because the destination account does not exist. The message is effectively sent into a void.
What did you expect?
expected the API to send the message to the JID corresponding to the number exactly as it was provided in the request: 55758825XXXX@s.whatsapp.net.
What did you observe instead of what you expected?
Instead of using the provided number, the API incorrectly modified it by adding a ninth digit.
- The API received the number 55758825XXXX.
- It automatically transformed it into 557598825XXXX.
- It then sent the message to the JID of this new, incorrect number: 557598825XXXX@s.whatsapp.net.
Because this modified number is not a registered WhatsApp user, the message was sent into a void. The API response shows a PENDING status for this incorrect JID, and the message was never delivered to the intended recipient.
Screenshots/Videos
The JSON request and response logs provided below clearly illustrate the problem without the need for a screenshot. They show the number being sent without the '9' and the API responding with a JID that includes the '9'.
Which version of the API are you using?
v2.3.4
What is your environment?
Linux
Other environment specifications
Installation Type: Docker / VPS
Operating System: Ubuntu 22.04
Orquestration Tool: n8n
If applicable, paste the log output
API Request (Body sent to the endpoint)
This is the JSON body sent to /message/sendText. Note the number field does not have the '9'.
code
{
"number": "55758825XXXX",
"text": "olá",
"delay": 1200
}
API Response (Output received from the endpoint)
This is the JSON response from the API. Note the remoteJid now incorrectly includes the '9', and the status is PENDING.
[
{
"key": {
"remoteJid": "557598825XXXX@s.whatsapp.net",
"fromMe": true,
"id": "3EB0FADC419EA52B3FA68109A8BE5B3DC74379C9"
},
"pushName": "Você",
"status": "PENDING",
"message": {
"conversation": "olá"
},
"messageType": "conversation",
"messageTimestamp": 1759937910,
"instanceId": "30d132a4-ebc9-4856-873e-ee39969aafcb",
"source": "unknown"
}
]
Additional Notes
This issue appears to be a regression of a previously fixed bug.
The root cause is that the number sanitization logic for Brazil is too aggressive. It incorrectly assumes all mobile numbers must have a ninth digit, failing to account for valid exceptions.
Suggestion: The logic should be improved to first check if the provided number is a valid WhatsApp user as is before attempting to add the ninth digit.
Welcome!
What did you do?
This appears to be a regression of a previously fixed bug.
When sending a message to a valid Brazilian WhatsApp number that does not use the ninth digit (e.g., some landline-like numbers in DD 75 starting with 8), the Evolution API incorrectly forces the addition of a '9' after the area code.
This causes the message to be sent to a JID that is not a registered WhatsApp user. From the API's perspective, the message is sent (
status: PENDING), but it is never delivered to the intended recipient because the destination account does not exist. The message is effectively sent into a void.What did you expect?
expected the API to send the message to the JID corresponding to the number exactly as it was provided in the request: 55758825XXXX@s.whatsapp.net.
What did you observe instead of what you expected?
Instead of using the provided number, the API incorrectly modified it by adding a ninth digit.
Because this modified number is not a registered WhatsApp user, the message was sent into a void. The API response shows a PENDING status for this incorrect JID, and the message was never delivered to the intended recipient.
Screenshots/Videos
The JSON request and response logs provided below clearly illustrate the problem without the need for a screenshot. They show the number being sent without the '9' and the API responding with a JID that includes the '9'.
Which version of the API are you using?
v2.3.4
What is your environment?
Linux
Other environment specifications
Installation Type: Docker / VPS
Operating System: Ubuntu 22.04
Orquestration Tool: n8n
If applicable, paste the log output
API Request (Body sent to the endpoint)
This is the JSON body sent to /message/sendText. Note the number field does not have the '9'.
code
API Response (Output received from the endpoint)
This is the JSON response from the API. Note the remoteJid now incorrectly includes the '9', and the status is PENDING.
Additional Notes
This issue appears to be a regression of a previously fixed bug.
The root cause is that the number sanitization logic for Brazil is too aggressive. It incorrectly assumes all mobile numbers must have a ninth digit, failing to account for valid exceptions.
Suggestion: The logic should be improved to first check if the provided number is a valid WhatsApp user as is before attempting to add the ninth digit.