Genuka WA docs

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éroCode renvoyéCe qu'il faut faire
Supprimé du compte WhatsApp33Vérifier l'identifiant, puis rajouter et reconnecter le numéro
Désenregistré de la Cloud API, mais toujours présent133010 : « 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éenregistrer133015 : la suppression n'est pas terminéeAttendre 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é :

Code 100, sous-code 33
{
  "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.

CanalCe que vous recevez
POST /api/v1/messages400 send_unknown (ou 409 send_config si Meta répond 401 ou 403), meta.code: 33
GET /api/v1/numbers/{id}/health422 meta_error (ou 403 si Meta répond 401 ou 403), avec le même objet meta
GET /api/v1/numbers?refresh=trueLe numéro revient avec "refreshed": false et un refreshError
CampagneChaque 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 connectionId de 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).

Sources

Sur cette page