On 7/18/2022, we are releasing updates to the API mainly concerning delays caused by contact verification, and updates regarding status codes. We want to reassure you that these will NOT cause any compatibility issues ( No backward compatibility issues specifically).
Please read the below list of requirements and updates carefully.
1. Current requirements by Meta & WhatsApp:
- Users should expect the messages they receive. Sending spam, and promotional messages to strangers can impose limits on your account or even result in bans. Therefore, make sure to obtain end-user opt-in before initiating conversations. Read more here
- User experience is important, because if end-users receive unwanted messages from an unfamiliar number, they might report the account, and the related account will be unable to send further messages until Meta/WhatsApp lifts the ban or the limits.
- Meta may also block related WhatsApp Business API accounts when too many messages are sent to unverified contacts, even if this contact has opted in outside of WhatsApp.
- Disclaimer: These are requirements by WhatsApp (Please read the commerce policy carefully) and it is passed through to BSPs and ultimately software vendors like get.chat. Your clients can opt-in through methods that don’t involve our inbox or API (i.e. SMS) and therefore get.chat can’t be responsible for breaches of WhatsApp commerce policy made by your account.
2. Status quo and performance-related issues:
- Based on the point mentioned above, It is recommended that you build chat flows that involve an opt-in and ensure that new clients initiate the conversation themselves. Otherwise, the database will lack the necessary contact info and the contact might be considered unverified.
- For your convenience, get.chat always verifies WhatsApp contacts on your behalf when needed when you create the message using “POST /api/v1/messages/” endpoint. Read more
- Although it’s not the case for existing chats, you could run into performance issues if the Chat does not exist. That’s because each new conversation requires a contact verification procedure that takes significantly longer than creating the message itself.
- That being said, if your chat flows are created in a way where most conversations are business-initiated you might run into performance issues with our default API functionalities.
3. Upcoming Integration API Improvements – delays caused by the contact verification process
In the upcoming release, you will be able to specify that the message creation endpoint no longer performs contact verification on your behalf
Upcoming API parameter – “verify_contact”:
The update above will enable you to send messages to non-existing chats 5-10 times faster 🐇.
🚨 IMPORTANT: We expect you to be aware of the consequences of disabling contact verification (Please refer to points 1. and 2.
We guarantee that no limits or user experience issues will occur given that you are 100% sure that your recipients are aware of incoming messages.
4. Upcoming changes regarding HTTP status code
Our message creation endpoint will no longer reply with HTTP 200 status codes. It will either reply with 202 status code or other codes already listed in the documentation. ✅ Please note that those changes are backward-compatible: If you implemented your get.chat Integration API application correctly, your app should be handling both 200 and 202 status codes already
Current API:
New API:
Before the upcoming release, the message creation endpoint can reply to you with 200 status code when WhatsApp Business API message creation is successful. It can also reply with 400 status codes whenever WhatsApp Business API spots any mistakes in your HTTP request. This will no longer be valid, after the update, messages will always be added to the queue (returning 202 status code).
As mentioned above, the 202 status code branch should already be implemented by you, as this is one of the existing scenarios of the existing API already.
With the new release, we are also improving the 202 status code branch with error handling. As outlined above, by the time of reading this e-mail, an immediate response from WhatsApp Business API is returned: either 200 status code, or 400. Starting this release, every user-error that ends up with 400 status code returned by WhatsApp, will be instead delivered to your webhook receivers with a proper “statuses” event (included API documentation screenshot in section 3.)