--- title: "Ce que vous pouvez construire avec l'API et les webhooks QuotWay" description: "Six intégrations avec l'API REST et les webhooks signés de QuotWay (Enterprise) : ERP, CRM, devis headless, validations, BI - et ce que l'API ne fait pas." url: "https://www.quotway.com/fr/blog/quotway-api-webhooks-recipes" type: "blog post" category: "Shopify AI & integrations" published: "2026-09-30" verified: "2026-09-30" audience: "Marchands sur le forfait Enterprise, et développeurs et agences qui connectent QuotWay à un ERP, un CRM, une boutique headless ou un outil de BI" scope: "L'API REST v1 et les webhooks sortants de QuotWay tels que lancés le 30 septembre 2026 : six recettes d'intégration avec leurs événements, endpoints et pièges, les choix de conception de l'API, ses limites, et les questions à poser à l'API de n'importe quelle application de devis" locale: "fr" source: "QuotWay - B2B Quote & Negotiation App for Shopify" --- # Ce que vous pouvez construire avec l'API et les webhooks QuotWay QuotWay dispose désormais d'une API REST publique et de webhooks sortants signés, sur le forfait Enterprise - y compris pendant l'essai gratuit de 14 jours. Ensemble, ils permettent au reste de vos outils de suivre vos devis sans que personne ne ressaisisse un chiffre : votre ERP apprend qu'un devis est accepté au moment où l'acheteur l'accepte, votre affaire dans le CRM affiche le montant réellement convenu, une boutique headless ou une application commerciale peut envoyer des demandes de devis, et votre équipe est prévenue des validations là où elle travaille déjà. Il y a une chose que l'API ne fait jamais : fixer un prix. L'API enregistre ce que demandent les acheteurs et envoie des propositions que votre équipe a déjà chiffrées ; les prix, votre prix plancher et vos règles de validation restent dans QuotWay, où votre équipe les contrôle. Cet article présente six choses à construire, le piège de chacune, les raisons de la conception de l'API, et les questions à poser à l'API de n'importe quelle application de devis. La référence se trouve dans [la documentation de l'API](/docs/api) ; chaque fait cité ici y correspond au 30 septembre 2026. ## Ce qui est disponible | Élément | Ce qu'il vous apporte | | --- | --- | | API REST v1 sur `api.quotway.com` | Lire les devis (lignes, totaux, événements, PDF, statistiques), créer des demandes de devis, publier des messages, envoyer une proposition que votre équipe a déjà enregistrée | | Webhooks sortants | Une requête HTTPS signée pour 25 événements de devis - de la nouvelle demande jusqu'aux propositions, contre-offres, acceptation, conversion et paiement, plus chaque décision de validation | | Flux d'événements | `GET /v1/events` : les 30 derniers jours d'événements, dans l'ordre, pour rattraper tout ce qu'un récepteur a manqué | | Clés | À scopes (`read_quotes`, `read_customer_data`, `read_analytics`, `write_quotes`, `manage_webhooks`), expiration et liste d'adresses IP autorisées en option, 24 heures de chevauchement quand vous renouvelez une clé ; clés `qw_test_` pour les boutiques de développement | | Spécification | OpenAPI 3.1 sur `https://api.quotway.com/openapi.json` - à importer dans Postman, Insomnia ou un générateur de code | Les clés sont créées par un administrateur de la boutique dans **Paramètres → Intégrations → Clés API**. Les limites sont de 120 requêtes par minute par clé et de 300 par boutique. ## 1. Prévenir votre ERP dès qu'un accord est conclu **Événements :** `quote.accepted`, `quote.partially_accepted`, `quote.converted` · **Scope :** `read_quotes` Quand un acheteur accepte, un webhook atteint votre endpoint en quelques instants. Votre gestionnaire le vérifie, répond `200`, puis récupère le devis complet pour créer ou mettre à jour l'enregistrement de vente que votre ERP tient pour l'affaire - le numéro de devis, la société de l'acheteur, les lignes convenues et les totaux. Quand le devis devient une commande provisoire Shopify, `quote.converted` est émis une fois par commande provisoire, avec le lien que votre ERP peut conserver à côté de la commande - [comment cette conversion se limite à exactement une commande provisoire](/blog/idempotent-draft-order-creation) est une histoire d'ingénierie à part entière. La commande elle-même doit toujours arriver dans l'ERP comme vos autres commandes - par votre connecteur Shopify existant - et la commande provisoire convertie porte la référence du devis pour que les deux se rejoignent. Le webhook ajoute la négociation qui se trouve derrière la commande ; il ne remplace pas la synchronisation des commandes. [Les modèles d'intégration ERP, CRM et PIM](/blog/shopify-b2b-erp-crm-pim-integration-patterns) précisent quel système doit écrire quel champ. Le gestionnaire, avec la bibliothèque officielle Standard Webhooks : ```js import express from "express"; import { Webhook } from "standardwebhooks"; const wh = new Webhook(process.env.QUOTWAY_WEBHOOK_SECRET); // "whsec_…" const app = express(); // Keep the body raw for this route - verification needs the exact bytes. app.post("/hooks/quotway", express.raw({ type: "application/json" }), async (req, res) => { let event; try { event = wh.verify(req.body.toString("utf8"), req.headers); } catch { return res.status(400).send("Invalid signature"); } const eventId = req.headers["webhook-id"]; if (await alreadyProcessed(eventId)) return res.sendStatus(200); await enqueueForProcessing(eventId, event); // fetch event.data.url and upsert, in the background res.sendStatus(200); }); ``` **Le piège :** les livraisons sont faites *au moins une fois* et *pas dans l'ordre*. Le même événement peut arriver deux fois, et une relance une heure plus tard transporte le devis tel qu'il est *à ce moment-là*. Dédoublonnez donc sur l'en-tête `webhook-id`, ordonnez selon `data.sequence`, et pour tout ce que vous écrivez dans un système de référence, récupérez le devis depuis `data.url` plutôt que de vous fier au résumé du payload. ## 2. Garder l'affaire du CRM sur le montant réellement convenu **Événements :** les événements de négociation et de résultat · **Scope :** `read_quotes` (plus `read_customer_data` si le CRM a besoin des coordonnées de l'acheteur) Une affaire de CRM qui suit un devis a besoin de deux choses : la bonne étape et le bon montant. Les étapes se font directement correspondre : | Événement QuotWay | Étape de l'affaire | | --- | --- | | `quote.created` | Nouvelle demande | | `quote.proposal_sent` | Proposition envoyée | | `quote.countered` | Négociation | | `quote.merchant_approval.requested` | Revue interne | | `quote.accepted` | Gagnée | | `quote.partially_accepted` | Gagnée en partie - les lignes non décidées sont toujours ouvertes | | `quote.declined`, `quote.buyer_approval.rejected` | Perdue | | `quote.expired` | Expirée - à relancer, pas forcément perdue | | `quote.order_completed` | Payée | Le montant est l'endroit où les CRM se trompent le plus souvent. Sur une acceptation partielle, le `total` du devis affiche toujours toute l'offre initiale - c'est ce qui a été *proposé*, et il n'est jamais réécrit. Enregistrez plutôt `totals.headline` : c'est le chiffre sur lequel agir, et `totals.headline_mode` indique pourquoi c'est ce chiffre (`none` ou `full` - le total de l'offre ; `decided` ou `open` - le total accepté). Quand le mode est `open`, `still_open_total` indique ce qui reste en jeu, pour qu'une affaire puisse afficher à la fois la part convenue et la part sur laquelle l'acheteur ne s'est pas encore décidé. **Le piège :** une ligne que l'acheteur n'a pas retenue lors d'une acceptation partielle est *toujours ouverte*, pas refusée. La classer en « perdue » sous-estime le pipeline et envoie une relance à un acheteur qui n'a pas dit non. ## 3. Recevoir des demandes de devis d'une boutique headless ou d'une application commerciale **Endpoint :** `POST /v1/quotes` · **Scope :** `write_quotes` Une boutique Hydrogen, une application de comptoir professionnel ou l'outil d'un commercial peut envoyer une demande de devis de la même façon que le bouton « Demander un devis » de la boutique en ligne - depuis son serveur, avec la clé conservée côté serveur : ```bash curl https://api.quotway.com/v1/quotes \ -H "Authorization: Bearer $QUOTWAY_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: 9d3e1f7a-5b2c-4e8d-a1f0-6c7b8a9d0e12" \ -d '{ "buyer": { "email": "buyer@example.com", "name": "Dana Ortiz", "company_name": "Acme Restaurant Group" }, "lines": [ { "variant_id": "gid://shopify/ProductVariant/4455667788", "quantity": 100, "requested_price": "11.50" } ], "notes": "Delivery to our Denver kitchen, please." }' ``` La demande passe par le même circuit d'entrée que la boutique : vos règles de ciblage décident si elle est autorisée, les champs personnalisés de votre formulaire de devis sont validés, vos règles d'automatisation s'exécutent, et votre équipe reçoit l'e-mail « nouveau devis » habituel. `requested_price` n'est que le prix visé par l'acheteur - le prix que votre équipe propose est fixé dans QuotWay. Transmettez un `customer_id` Shopify et QuotWay vérifie les vrais tags du client et ses rattachements aux sociétés B2B ; s'il est contact d'un site d'une société, le devis tient compte de la société, exactement comme pour un acheteur connecté sur votre boutique. **Le piège :** la réponse `201` indique `submitted`, mais vos règles d'automatisation agissent sur le nouveau devis en quelques instants - une règle d'envoi automatique peut envoyer une proposition, une règle de refus automatique peut le refuser. Ne supposez pas qu'un devis que vous venez de créer est toujours `submitted` ; écoutez `quote.proposal_sent`, `quote.declined` et `quote.assigned`, ou récupérez-le à nouveau avant d'agir. Et envoyez toujours un `Idempotency-Key` : si la connexion tombe après la création du devis, la nouvelle tentative renvoie la même réponse au lieu d'une demande en double. ## 4. Placer les demandes de validation là où votre équipe travaille déjà **Événements :** `quote.merchant_approval.requested`, `.granted`, `.rejected` Quand une proposition a besoin d'un accord interne - une remise au-delà de votre seuil, un devis de montant élevé - `quote.merchant_approval.requested` est émis. Un petit relais peut en faire un message dans le canal que surveillent vos valideurs, avec le numéro de devis et un lien pour l'ouvrir dans QuotWay ; `.granted` et `.rejected` bouclent la boucle. Tout système capable de recevoir un webhook signé peut le faire : votre propre endpoint, ou le déclencheur webhook générique d'une plateforme d'intégration. La validation elle-même a toujours lieu dans QuotWay, selon vos règles de validation. Le message est une notification, pas un bouton qui valide. **Le piège :** par conception, les payloads des webhooks ne contiennent ni noms d'acheteurs, ni e-mails, ni texte libre ; le message a donc ce qu'il lui faut pour être acheminé (le numéro de devis, le statut, les totaux) et rien de personnel. Si vos valideurs ont besoin de plus, récupérez le devis avec une clé qui a les bons scopes - et réfléchissez à deux fois avant de coller les coordonnées d'un acheteur dans un canal partagé. ## 5. Importer les indicateurs de devis dans votre outil de BI **Endpoint :** `GET /v1/analytics/summary` · **Scope :** `read_analytics` ```bash curl -G https://api.quotway.com/v1/analytics/summary \ -H "Authorization: Bearer $QUOTWAY_API_KEY" \ --data-urlencode "period=week" \ --data-urlencode "limit=4" ``` Il renvoie les mêmes indicateurs précalculés que le tableau de bord statistique de QuotWay - volume, valeur acceptée et convertie, pipeline et délais de réponse - par jour, semaine ou mois, en UTC et dans la devise de base de la boutique. Une tâche planifiée qui les importe dans un entrepôt de données ou un tableur constitue toute l'intégration ; la clé n'a besoin d'aucun accès aux données personnelles. ## 6. Libérer les propositions après une vérification dans un autre système **Endpoint :** `POST /v1/quotes/{id}/send-proposal` · **Scope :** `write_quotes` Certaines équipes chiffrent dans QuotWay mais veulent qu'un autre système décide *quand* une proposition part - un ERP qui confirme la marge ou le stock, une étape du CRM qui marque l'affaire comme prête, une tâche qui libère les propositions de la matinée à neuf heures. `send-proposal` envoie la proposition que votre équipe a déjà enregistrée dans l'éditeur de proposition, avec exactement les contrôles que fait l'admin : le devis doit pouvoir recevoir une proposition, les prix de catalogue d'un devis rattaché à une société sont relus depuis Shopify, une ligne sous votre prix plancher bloque l'envoi sauf si l'appel le confirme explicitement (la même confirmation que demande l'admin), et une règle de validation met la proposition en attente d'accord au lieu de l'envoyer. **Le piège :** si personne n'a enregistré de proposition, il n'y a rien à envoyer - l'appel renvoie `409 no_staged_proposal`. L'API envoie ce que votre équipe a chiffré ; elle ne chiffre jamais. ## Pourquoi l'API est conçue ainsi Six choix façonnent l'API, et chacun est une raison de faire confiance à ce qu'elle fait. 1. **Elle ne fixe jamais les prix.** Le prix est l'endroit où un outil de devis fait gagner ou perdre de l'argent, et il reste entre les mains de votre équipe - le prix plancher, les règles de validation et l'éditeur de proposition s'appliquent à tout, y compris à ce qui arrive par l'API. Il n'existe aucun endpoint pour chiffrer ou modifier des lignes, accepter ou refuser à la place d'un acheteur, ou convertir un devis en commande provisoire. 2. **Les webhooks ne transportent aucune donnée personnelle.** Un payload contient des identifiants, le type d'événement, et le numéro, le statut, la devise et les totaux du devis - jamais le nom, l'e-mail, le téléphone, l'adresse ou le message d'un acheteur. Les coordonnées de l'acheteur ne viennent que de l'API, et seulement avec une clé qui a le scope `read_customer_data`. Un endpoint mal configuré ne peut pas divulguer ce qu'il n'a jamais reçu. 3. **Les webhooks suivent la spécification Standard Webhooks.** Les en-têtes de signature sont les en-têtes standard : vous vérifiez donc avec les bibliothèques officielles `standardwebhooks` plutôt qu'avec du code fait maison. Pendant la rotation d'un secret, les livraisons sont signées avec les deux secrets pendant 24 heures, pour que rien n'échoue pendant la bascule. 4. **Les livraisons sont relancées, puis rejouables.** Une livraison échouée est relancée jusqu'à huit tentatives en tout, sur environ 3,7 jours ; un endpoint qui continue d'échouer est désactivé et votre équipe est prévenue par e-mail. Tout ce qui a été manqué reste dans `GET /v1/events` pendant 30 jours, dans l'ordre. 5. **Chaque écriture est idempotente.** Chaque `POST` accepte un `Idempotency-Key`, respecté pendant 24 heures, pour qu'une requête relancée ne puisse pas créer un second devis ni envoyer une proposition deux fois. 6. **Les erreurs sont précises et stables.** Les erreurs suivent la RFC 9457 avec un `code` stable - `not_eligible`, `below_price_floor`, `insufficient_scope` - qui renvoie à sa propre entrée dans [la référence des erreurs](/docs/api/errors), pour qu'une intégration puisse bifurquer sur un code au lieu d'analyser une phrase. ## Ce qu'elle ne fait pas (encore) - **Aucun connecteur prêt à l'emploi.** Il n'y a aucune application dans l'annuaire Zapier, aucun serveur MCP, et aucune connexion native à HubSpot, Salesforce ou Klaviyo. Vous pouvez connecter chacun de ces systèmes *via* l'API et les webhooks. - **Aucun SDK, aucune API GraphQL et aucun sandbox.** La spécification OpenAPI s'importe dans la plupart des outils ; les clés `qw_test_` fonctionnent sur une boutique de développement Shopify, avec les vraies données de cette boutique. - **Aucune fixation de prix, modification de ligne, acceptation ou conversion via l'API** - par conception, comme expliqué plus haut. ## Les questions à poser à l'API de n'importe quelle application de devis Quelle que soit l'application que vous évaluez, ces questions distinguent une API sur laquelle construire d'une ligne sur une page de tarifs : - La documentation est-elle publique, avec une spécification lisible par une machine que vous pouvez importer ? - Les webhooks sont-ils signés, et pouvez-vous les vérifier avec une bibliothèque standard plutôt qu'avec du code sur mesure ? - Que devient une livraison que votre endpoint manque - pendant combien de temps est-elle relancée, et pouvez-vous la rejouer ? - Une requête relancée peut-elle créer un doublon, ou les écritures acceptent-elles une clé d'idempotence ? - Les payloads des webhooks contiennent-ils des données client, et pouvez-vous limiter une clé pour qu'elle ne puisse en lire aucune ? - L'API peut-elle modifier les prix - et si oui, votre prix plancher et vos validations s'appliquent-ils toujours ? - De quel préavis disposez-vous avant un changement incompatible ? (Les [Conditions d'utilisation de l'API](/api-terms) de QuotWay s'engagent sur au moins six mois.) Le reste de l'évaluation d'une application - traitement des données, versions de l'API, ce qui est imposé côté serveur - se trouve dans [comment évaluer une application B2B pour Shopify](/blog/shopify-b2b-app-evaluation-checklist). ## Pour commencer 1. Vérifiez que la boutique est sur Enterprise, ou en essai de 14 jours - la page [tarifs](/pricing) détaille les forfaits. 2. Créez une clé dans **Paramètres → Intégrations → Clés API** avec uniquement les scopes nécessaires, et acceptez les Conditions d'utilisation de l'API. 3. Suivez [le guide de démarrage rapide](/docs/api/quickstart) : vérifiez la clé avec `/v1/ping`, listez les devis, créez une demande - une dizaine de minutes. 4. Ajoutez un endpoint de webhook dans **Paramètres → Intégrations → Webhooks**, et envoyez un ping de test. Le côté produit est sur [la page de la fonctionnalité API et webhooks](/features/api-webhooks). ## Questions fréquentes ### QuotWay a-t-il une API ? Oui. QuotWay dispose d'une API REST publique (v1) sur `api.quotway.com` et de webhooks sortants signés, sur le forfait Enterprise - y compris pendant l'essai gratuit de 14 jours. Elle lit les devis, crée des demandes de devis, publie des messages et envoie des propositions que votre équipe a déjà chiffrées ; elle ne fixe jamais les prix. ### Quel forfait inclut l'API et les webhooks QuotWay ? Le forfait Enterprise (199 $ par mois), et une boutique en essai gratuit de 14 jours peut utiliser les deux. Si une boutique passe à un forfait inférieur, ses clés et ses endpoints de webhook sont conservés mais mis en pause jusqu'à son retour sur Enterprise. ### Puis-je créer des devis depuis une boutique Shopify headless ? Oui - avec `POST /v1/quotes` depuis le serveur de votre boutique. La demande passe par les mêmes règles de ciblage, la même validation des champs personnalisés et les mêmes règles d'automatisation que le bouton de devis de la boutique en ligne, et arrive comme une demande que votre équipe chiffre. ### Les webhooks QuotWay contiennent-ils des données client ? Non. Les payloads des webhooks contiennent des identifiants, le type d'événement, et le numéro, le statut, la devise et les totaux du devis - ni noms, ni e-mails, ni numéros de téléphone, ni adresses, ni messages. Les coordonnées de l'acheteur ne viennent que de l'API, avec une clé qui a le scope `read_customer_data`. ### Comment vérifier la signature d'un webhook QuotWay ? QuotWay suit la spécification Standard Webhooks : utilisez donc la bibliothèque officielle `standardwebhooks` de votre langage. Transmettez-lui le corps brut de la requête, les en-têtes `webhook-id`, `webhook-timestamp` et `webhook-signature`, et le secret `whsec_` de votre endpoint. Rejetez tout ce qui ne se vérifie pas. ### L'API peut-elle fixer les prix ou accepter un devis à la place de l'acheteur ? Non. Il n'existe aucun endpoint pour chiffrer ou modifier des lignes, accepter ou refuser à la place de l'acheteur, ou convertir un devis. Envoyer une proposition via l'API envoie celle que votre équipe a enregistrée, avec les mêmes contrôles de prix plancher et de validation que dans l'admin. ### QuotWay peut-il se connecter à Zapier ou à HubSpot ? Via l'API et les webhooks, oui - par exemple, un webhook envoyé au déclencheur webhook générique d'une plateforme d'intégration, ou votre propre service qui met à jour le CRM. Il n'existe aujourd'hui aucune application QuotWay dans l'annuaire Zapier et aucune connexion native à HubSpot. ## Sources Documentation de l'API QuotWay, lue le 30 septembre 2026 : - [Vue d'ensemble de l'API](/docs/api), [démarrage rapide](/docs/api/quickstart) et [authentification, clés et scopes](/docs/api/authentication) - [Webhooks](/docs/api/webhooks) - le catalogue des événements, les payloads, les signatures, les relances et l'ordre - [Créer des devis](/docs/api/create-quotes), [messages et propositions](/docs/api/messages-and-proposals), [l'objet devis](/docs/api/quote-object), [les événements](/docs/api/events), [les statistiques](/docs/api/analytics) et [les limites de débit](/docs/api/rate-limits) - [Erreurs](/docs/api/errors) et la [spécification OpenAPI](https://api.quotway.com/openapi.json) - [Conditions d'utilisation de l'API](/api-terms)