Aller au contenu
Wiz Message
Compatible Cloud API

Déjà développé sur WhatsApp Cloud API ? Changez l'hôte et le jeton.

Ce n'est pas « nous avons aussi une API ». C'est la même API. Les chemins correspondent à ceux de Meta, les corps de requête correspondent, les réponses correspondent, et les erreurs reviennent dans l'enveloppe de Meta — donc la gestion d'erreurs que vous avez déjà écrite continue de fonctionner. Pointez votre client vers un autre hôte, changez le jeton, et arrêtez-vous là.

Inclus dansWiz BotWiz CampaignWiz Pro

Voir les formulesVoir les tarifs
Un hôte et un jeton. Le reste de votre intégration n'est pas touché
Deux changements
Les échecs reviennent dans l'enveloppe d'erreur de Meta, votre gestion actuelle s'applique donc toujours
Les mêmes erreurs
La version épinglée dans votre URL continue de fonctionner après que Meta l'a retirée
À l'épreuve des versions

À qui ça s'adresse

L'entreprise ou l'agence qui a déjà payé un développeur pour intégrer le Cloud API de Meta et ne repaiera pas pour migrer.

La crainte que ça lève

« Changer de plateforme, c'est réintégrer. » Pas quand les endpoints, les charges utiles et les formes d'erreur sont identiques.

Comment se passe la migration

  1. Créez une clé

    Générez une clé d'API dans le tableau de bord. Elle se présente dans la même forme d'en-tête qu'un jeton Meta.

  2. Changez l'URL de base

    Pointez votre client existant vers l'hôte compatible plutôt que vers celui de Meta.

  3. Changez le jeton

    Utilisez votre clé comme jeton bearer. Rien ne change dans la façon dont vous construisez vos requêtes.

  4. Lancez vos tests existants

    Mêmes chemins, mêmes corps, mêmes réponses, même enveloppe d'erreur — votre suite de tests est la vérification de la migration.

Ce qui est reproduit

Les endpoints que les intégrations utilisent réellement, aux chemins que Meta documente.

  • L'envoi de messages sur le même endpoint de messages que vous appelez déjà
  • Le marquage comme lu et les indicateurs de saisie, avec le même corps de requête
  • L'envoi de médias, renvoyant un identifiant dans la forme que vous analysez déjà
  • La liste des modèles de message
  • Les métadonnées de média, le téléchargement et la suppression — les métadonnées renvoient une URL fonctionnelle que votre client récupère sans savoir à qui elle appartient
  • Un passage avec liste d'autorisation pour les autres chemins documentés
  • Des erreurs dans l'enveloppe de Meta, de sorte que votre gestion d'erreurs existante continue de fonctionner

Un épinglage de version qui survit aux retraits de Meta

Le segment de version dans l'URL est accepté puis ignoré. Cela ressemble à un raccourci et c'est en réalité un avantage qu'il vaut la peine d'énoncer : un client épinglé à une ancienne version continue de fonctionner après son retrait par Meta, et en épingler une plus récente ne vous engage pas dans un comportement non déployé. La version inscrite dans votre code cesse d'être une corvée de maintenance.

Une liste d'autorisation, pas un proxy aveugle

Seuls les chemins documentés existent, et chacun vérifie que l'identifiant présent dans le chemin appartient à la clé qui appelle. La surface reste ainsi auditable — vous pouvez dire exactement jusqu'où va cet endpoint — et une erreur dans votre client reçoit une réponse honnête au lieu d'être transmise ailleurs. Chaque envoi passe toujours par la plateforme : les mêmes limitations de débit et protections de compte s'appliquent.

Bon à savoir

Là où s'arrête cette fonctionnalité, dit simplement — pour qu'aucune surprise ne vous attende après l'achat.

  • Nécessite un abonnement actif et passe les mêmes contrôles de droits et de débit que le reste de l'API.
  • Il s'agit d'une liste d'autorisation, pas d'un proxy ouvert. Seuls les chemins documentés existent, et chacun vérifie que l'identifiant du chemin appartient à votre clé.
  • Le segment de version est reconnu puis ignoré — les appels vont toujours vers la version configurée de la plateforme. C'est délibéré, et c'est pourquoi un ancien épinglage continue de fonctionner.
  • GET, POST et DELETE uniquement. Ni PUT ni PATCH, car y répondre par une erreur crédible serait moins honnête qu'un 404.
  • Les envois passent toujours par la passerelle de la plateforme plutôt que de sortir directement : les limitations de débit et protections au niveau du compte s'appliquent encore.

Inclus dans

Cette fonctionnalité fait partie des formules ci-dessous.

  • Wiz Bot
  • Wiz Campaign
  • Wiz Pro
Comparer les formules et les tarifs
FAQ

Questions fréquemment posées

Quelle part de mon code doit changer ?

L'URL de base et le jeton. Chemins, corps de requête, réponses et formes d'erreur sont identiques — c'est tout l'objet de cette fonctionnalité.

Est-ce vraiment la même API, ou seulement une API similaire ?

Les mêmes chemins, les mêmes corps de requête, les mêmes réponses et la même enveloppe d'erreur. « Similaire » vous coûterait quand même une réécriture ; ceci est conçu pour que vos tests existants passent sans modification.

Et le numéro de version dans mes URL ?

Il est accepté puis ignoré : un client épinglé à une ancienne version continue de fonctionner après son retrait par Meta. Vous n'avez pas à courir après les dépréciations.

Quelles méthodes HTTP sont prises en charge ?

GET, POST et DELETE. Ni PUT ni PATCH — nous préférons renvoyer un 404 honnête qu'une erreur convaincante pour quelque chose qui n'existe pas.

Tout ce que propose Meta est-il disponible ?

Non. Il s'agit d'une liste d'autorisation délibérée des chemins documentés, pas d'un proxy aveugle, afin que la surface reste auditable.

Est-ce que je conserve les fonctionnalités propres à la plateforme ?

Oui. Les envois passent par la même plateforme que celle qu'utilise votre tableau de bord : boîte partagée, analyses, protections de compte et limitations de débit s'appliquent toujours.

Changez sans réintégrer

Changez l'hôte, changez le jeton, et lancez vos tests existants.

Voir les formules

Découvrir Plus de Fonctionnalités

Découvrez les autres outils qui font de WizMessage la plateforme WhatsApp complète.