Erreur WhatsApp 33 : numéro supprimé, cause et solution
Erreur WhatsApp 33 sur la Cloud API : le numéro WhatsApp Business visé a été supprimé ou l'identifiant n'est plus le bon. Diagnostic et reconnexion.
L'erreur WhatsApp 33 signifie, selon Meta, que le numéro WhatsApp Business visé par la requête a été supprimé. L'identifiant de numéro que vous utilisez ne pointe donc plus sur un numéro actif. Vérifiez cet identifiant ; si le numéro a bien été supprimé, il faut le reconnecter. Renvoyer la même requête ne changera rien.
Que signifie l'erreur 33 ?
Meta la range dans les « autres erreurs » de la Cloud API :
« The business phone number has been deleted. » — solution proposée : « Verify that the business phone number is correct. » — Meta, codes d'erreur de la Cloud API
La solution de Meta envisage donc deux causes : un numéro réellement supprimé, ou un identifiant qui n'est pas le bon.
Supprimé, désenregistré ou en cours de suppression ?
Trois états proches produisent trois codes différents :
| État du numéro | Code renvoyé | Ce qu'il faut faire |
|---|---|---|
| Supprimé du compte WhatsApp | 33 | Vérifier l'identifiant, puis rajouter et reconnecter le numéro |
| Désenregistré de la Cloud API, mais toujours présent | 133010 : « Phone number not registered on the WhatsApp Business Platform » | L'enregistrer de nouveau |
| Supprimé il y a quelques minutes, et qu'on tente de réenregistrer | 133015 : la suppression n'est pas terminée | Attendre 5 minutes avant de réessayer |
Les libellés viennent de la même page de Meta. Meta précise par ailleurs que désenregistrer un numéro ne le supprime pas et n'efface pas son historique de messages (Meta, Registration).
Erreur 33 ou sous-code 33 ?
Regardez d'abord quel champ porte le 33. Graph peut aussi répondre par le code 100 avec
error_subcode: 33, une réponse qui ne parle pas d'un numéro supprimé :
{
"error": {
"message": "Unsupported post request. Object with ID '123456789012345' does not exist, cannot be loaded due to missing permissions, or does not support this operation.",
"type": "GraphMethodException",
"code": 100,
"error_subcode": 33
}
}Cette réponse a été rapportée sur le forum Activepieces. Elle dit que l'objet visé n'existe pas, ou que le jeton n'y a pas accès. Les causes rapportées sont un identifiant erroné, un jeton qui a perdu l'accès à cet actif ou un accès partenaire retiré (Fast2SMS). Un numéro supprimé peut la produire, un accès retiré aussi : ne concluez pas à une suppression avant d'avoir vérifié l'accès, voir erreur 100 et erreur 200.
Quand l'erreur 33 apparaît-elle ?
- Le numéro a été supprimé dans WhatsApp Manager par quelqu'un du côté de l'entreprise, alors qu'une intégration continuait de l'utiliser.
- L'identifiant est faux ou périmé : copié depuis un autre compte, conservé dans une configuration après un changement de numéro, ou confondu avec le numéro affiché.
Où la voir dans Genuka WA ?
Genuka WA enregistre l'identifiant du numéro au moment de la connexion ; le connectionId que vous
transmettez y renvoie. Si l'entreprise supprime ensuite le numéro dans WhatsApp Manager, les appels
sur cette connexion sont refusés : avec meta.code: 33, ou avec meta.code: 100 et
meta.subcode: 33, la réponse décrite plus haut.
Genuka ne range pas 33 dans une classe dédiée : la classe découle du statut HTTP renvoyé par Meta,
unknown le plus souvent, et n'est pas réessayable.
| Canal | Ce que vous recevez |
|---|---|
POST /api/v1/messages | 400 send_unknown (ou 409 send_config si Meta répond 401 ou 403), meta.code: 33 |
GET /api/v1/numbers/{id}/health | 422 meta_error (ou 403 si Meta répond 401 ou 403), avec le même objet meta |
GET /api/v1/numbers?refresh=true | Le numéro revient avec "refreshed": false et un refreshError |
| Campagne | Chaque destinataire passe failed, avec le message de Meta |
Comment corriger l'erreur 33 ?
Si vous passez par Genuka WA
Confirmez que le numéro ne répond plus. GET /api/v1/numbers/{id}/health interroge Meta pour
ce seul numéro : un refus meta_error dont meta.code ou meta.subcode vaut 33 le confirme en un
appel. Lisez aussi son statut dans GET /api/v1/connections : s'il n'est plus connected, l'accès
a peut-être été retiré plutôt que le numéro supprimé, voir erreur 200.
Faites vérifier le numéro dans WhatsApp Manager, onglet Phone numbers, par quelqu'un qui a
accès au compte WhatsApp de l'entreprise. S'il y figure toujours, l'identifiant enregistré n'est
plus le bon : écrivez au support Genuka avec x-request-id et meta.traceId.
S'il a été supprimé, reconnectez-le. L'entreprise repasse par le
lien de connexion, qui ajoute le numéro par l'Embedded Signup de Meta et
l'enregistre sur la Cloud API. Relisez ensuite GET /api/v1/connections et utilisez le
connectionId qui y figure pour ce numéro, plutôt que celui que vous aviez conservé.
Si Meta a donné un nouvel identifiant au numéro, la reconnexion crée une nouvelle connexion, qui
demande une place libre dans votre plan. Si toutes sont occupées, libérez d'abord l'ancienne depuis
la fiche du client dans le tableau de bord (Libérer la place) : elle n'envoie plus, mais occupe
encore une place, et la reconnexion serait refusée avec plan_limit_numbers.
Si Meta a donné un nouvel identifiant au numéro, les messages, templates et statistiques déjà enregistrés par Genuka WA restent attachés à l'ancienne connexion.
Si vous appelez la Cloud API directement
Listez les numéros du compte avec GET /{WABA_ID}/phone_numbers et comparez leurs id à celui que
vous utilisez. Si le numéro n'y figure plus, rajoutez-le dans WhatsApp Manager, vérifiez-le, puis
enregistrez-le par POST /{PHONE_NUMBER_ID}/register
(Meta, Registration).
Juste après une suppression, attendez quelques minutes : Meta répond 133015 tant qu'elle n'est
pas terminée.
Comment éviter l'erreur 33 ?
- Coupez les envois avant de supprimer un numéro. Prévenez les équipes qui gèrent WhatsApp Manager : supprimer un numéro arrête immédiatement toute intégration qui l'utilise.
- Référencez la connexion, pas le numéro. Stockez le
connectionIdde Genuka WA, ou l'identifiant Meta du numéro, plutôt que le numéro affiché, qui ne sert pas d'identifiant à l'API. - Vérifiez la santé avant une grosse campagne. Un
GET /api/v1/numbers/{id}/healthéchoue tout de suite sur un numéro supprimé, au lieu de laisser chaque destinataire échouer un par un.
Quels codes sont liés ?
133010: le numéro existe mais n'est pas enregistré sur la Cloud API.133015: le numéro vient d'être supprimé et la suppression n'est pas terminée.- 100 : un paramètre inconnu ou mal orthographié ; avec le sous-code 33, un objet introuvable ou inaccessible.
- 200 : le compte n'est plus accessible, par exemple après un retrait d'accès.
FAQ
Quelle différence entre désenregistrer et supprimer un numéro ?
Désenregistrer rend le numéro inutilisable avec la Cloud API jusqu'à son réenregistrement, sans le supprimer ni effacer son historique. Supprimer le retire du compte WhatsApp : c'est ce cas qui produit l'erreur 33.
Faut-il réessayer un envoi refusé avec l'erreur 33 ?
Non. Tant que le numéro n'est pas reconnecté, chaque envoi sur cette connexion échouera de la même façon.
Mon historique de messages est-il perdu ?
Pas côté Genuka WA : ce qui a été enregistré reste attaché à l'ancienne connexion. Côté Meta, oui : supprimer un numéro supprime aussi son historique, alors que le désenregistrer le conserve (Meta, Registration).