POST avec un petit payload JSON à l’URL d’endpoint que vous avez configurée. Le payload vous indique ce qui a changé ; appelez l’API pour lire l’état actuel de l’objet.
Créer un webhook
Les webhooks se configurent dans l’application, pas via l’API.1
Ouvrir les paramètres des webhooks
Allez dans Paramètres › Développeur › Webhook et cliquez sur Nouveau.
2
Remplir le formulaire
- Nom (obligatoire) et Description (facultatif) vous aident à reconnaître le webhook.
- URL du point de terminaison (obligatoire) : l’URL publique qui reçoit les requêtes
POST. - Objet (obligatoire) : le type d’objet à surveiller : Devis, Produit, Client ou Segment client. Commande et Contrat sont affichés comme « bientôt » et ne peuvent pas encore être sélectionnés.
- Événement (obligatoire) : un ou plusieurs événements pour cet objet (Nouveau, Mise à jour, Suppression, et Validation pour les devis).
- Secret (facultatif) : une valeur de votre choix que Qwoty inclut dans chaque payload pour que vous puissiez vérifier que l’appel provient bien de Qwoty.
3
Enregistrer
Cliquez sur Enregistrer. La liste des webhooks affiche une colonne Dernière livraison (Réussie, Échec ou Jamais déclenché) pour vous aider à déboguer votre endpoint.

Événements
Le nom d’événement envoyé dans le payload est<object>.<event>.
Les événements sont envoyés que la modification ait été faite dans l’application ou via l’API.
Payload
Chaque livraison est unPOST avec Content-Type: application/json :
Sécuriser votre endpoint
Qwoty ne signe pas les requêtes de webhook : il n’y a ni en-tête de signature ni horodatage. Pour vérifier qu’un appel provient de Qwoty :- Définissez un Secret long et aléatoire sur le webhook.
- Dans votre endpoint, comparez le champ
secretdu corps JSON à la valeur que vous avez stockée, et rejetez la requête (par exemple avec401) si elles diffèrent. - N’exposez votre endpoint qu’en HTTPS, pour que le secret soit chiffré en transit.
Node.js (Express)
Livraison
- Qwoty fait une seule tentative par événement et par endpoint. Il n’y a aucune nouvelle tentative : une livraison échouée n’est pas renvoyée.
- La requête expire au bout de 10 secondes. Tout statut autre que
2xx, tout délai dépassé ou toute erreur réseau compte comme un échec et s’affiche comme Échec dans la colonne Dernière livraison. - L’ordre des événements n’est pas garanti.
Bonnes pratiques
- Répondez vite. Renvoyez immédiatement un
2xxet faites le traitement de manière asynchrone, bien en deçà du délai de 10 secondes. - Récupérez l’état le plus récent. Le payload ne fait qu’identifier l’objet : lisez-le via l’API (par exemple Récupérer un devis ou Récupérer un client) avant d’agir.
- Soyez idempotent. Un même objet peut déclencher plusieurs événements
updated’affilée ; assurez-vous que traiter deux fois le même événement est sans conséquence. - Réconciliez régulièrement. Les livraisons échouées n’étant pas renvoyées, lancez une synchronisation périodique avec les endpoints de liste (par exemple Lister les devis) si vous ne pouvez pas vous permettre de manquer un événement.

