OAuth2 pour les applications tierces

Uniquement pour les applications que d'autres clients WASync installent. Authorization Code avec PKCE, refresh tokens rotatifs et une limite structurelle.

Passez cette page si vous automatisez votre propre compte

Une API key permet de tout faire dans cette documentation, sans aucun mécanisme supplémentaire. OAuth sert exactement à un seul cas : votre application est installée par d'autres clients WASync, et ces clients doivent consentir aux connexions dont ils sont propriétaires.

Enregistrer l'application

Enregistrez-la sur https://developers.wasync.app/apps. Vous obtenez un client_id et un client_secret (affiché une seule fois). Vous définissez un ou plusieurs redirect_uri (comparés exactement lors de l'échange du token), un webhook_url facultatif et les scopes dont vous avez besoin.

Le flux

Authorization Code avec PKCE — S256 est obligatoire. Envoyez l'utilisateur vers /oauth/authorize avec response_type=code, votre client_id, redirect_uri, scope, un state et un code_challenge.

Endpoint	URL
Autorisation	`https://cloudapi.wasync.app/oauth/authorize`
Token (`client_secret_post`)	`https://cloudapi.wasync.app/oauth/token`
Découverte	`https://cloudapi.wasync.app/.well-known/oauth-authorization-server`

Ces URL — comme l'URL du serveur MCP — utilisent volontairement cloudapi.wasync.app. Ce sont des identifiants de protocole que votre bibliothèque cliente et nos documents de découverte ont déjà enregistrés : ils doivent donc correspondre octet pour octet. Seules l'URL de base REST et les pages destinées aux humains utilisent le domaine canonique developers.wasync.app.

Bitrix24. WASync affiche un court code utilisateur. Une personne disposant de l'accès en écriture à la zone API & Agents du portail le saisit sous Settings → API & Agents, en choisissant les connexions et les scopes. Tous les administrateurs Bitrix24 ont cet accès, de même que toute personne à qui un administrateur l'a accordé dans la matrice d'accès de la page Staff.

Standalone. Le développeur approuve sur https://developers.wasync.app/authorize — l'approbation est automatique lorsqu'il possède exactement un espace de travail comptant au moins une connexion.

Échanger le code

Token exchange

curl -X POST https://cloudapi.wasync.app/oauth/token \
  -d grant_type=authorization_code \
  -d code=$AUTH_CODE \
  -d redirect_uri=https://your.app/callback \
  -d client_id=$CLIENT_ID \
  -d client_secret=$CLIENT_SECRET \
  -d code_verifier=$CODE_VERIFIER

L'access_token dure 15 minutes. Le refresh_token dure 30 jours et change à chaque utilisation — enregistrez le nouveau de façon atomique et sérialisez les renouvellements entre vos workers, sinon deux workers en concurrence invalideront le token l'un de l'autre.

L'access token se place dans le même en-tête qu'une API key : Authorization: Bearer …. Les deux types d'identifiants donnent accès à tous les endpoints.

Une limite structurelle

Une autorisation n'est émise que sur des connexions qui existent déjà : une intégration uniquement OAuth ne peut donc pas créer la première connexion d'un espace de travail. Une API key le peut — c'est pourquoi le démarrage rapide commence par là.

Webhooks pour les applications OAuth

Une application OAuth définit webhook_url sur l'application elle-même au lieu d'appeler PUT /webhook, et l'autorisation doit avoir été approuvée avec whatsapp.events, sinon rien n'est livré. Tout le reste — le schéma de signature, la politique de nouvelles tentatives, les payloads — est identique au guide des webhooks.

Les abonnements créés avant le 24 juillet 2026 ne reçoivent que message.received ; ceux créés avant le 10 août 2026 ne reçoivent pas les événements de connexion. Réautorisez l'application pour obtenir les nouveaux types d'événements, ou écrivez au support pour demander leur ajout à votre abonnement existant.

Cette page vous a-t-elle été utile ?