ConnectWiz + API et webhooks
Intégration en productionL’API que nous vendons est celle que nous utilisons
Toute la plateforme est spécifiée dans un seul contrat OpenAPI à partir duquel notre propre panneau et notre application mobile sont générés — pas d’endpoint fantôme, pas de documentation qui dérive. Par-dessus : des clés Commerce API à portée limitée, des déclencheurs webhook sécurisés, et des flows qui appellent vos systèmes.
Développeurs
Ce qu’il fait — précisément
Un seul contrat qui fait foi
Un unique document OpenAPI 3 spécifie la plateforme ; nos propres clients TypeScript en sont générés — la documentation ne peut pas dériver du réel, puisque le réel est construit à partir d’elle.
Les clés Commerce API
Des clés émises par le locataire, avec des scopes explicites — lecture du catalogue, lecture des commandes, écriture des commandes — font tourner votre propre boutique ou application sur le même moteur de commandes, les prix étant toujours résolus côté serveur.
Webhooks entrants, sécurisés
Chaque déclencheur webhook de flow a sa propre URL et son propre secret, une vérification HMAC sur le corps brut et une protection contre le rejeu. Une charge utile peut nommer une personne ; elle ne peut jamais piloter les rouages du flow.
Le sortant passe par les flows
L’étape REST appelle vos systèmes exactement aux moments que vous dessinez sur le canevas — commande passée, consentement accordé, réservation faite.
Côté technique
Nos partis pris de conception d’API, annoncés
Les prix ne viennent jamais du client
Une requête de commande dit quoi et combien — le nom et le prix sont lus dans le catalogue à cet instant, côté serveur, et inscrits sur la ligne comme un instantané. Une requête trafiquée ne peut pas inventer une remise.
Les capacités avant les appels
Chaque surface d’intégration publie un contrat de capacités — sait-elle rapprocher par téléphone, lister les commandes invité, créer des commandes ? — et appeler au-delà d’un « non » déclaré lève une erreur immédiatement, au lieu d’échouer quelque part en profondeur.
Des erreurs qui veulent dire quelque chose
Le transport distingue « non autorisé » de « service indisponible » — de sorte que « la boutique est injoignable » n’est jamais affiché comme « ce client n’a jamais rien acheté ». Des erreurs nommées, c’est ce qui sépare une API d’un jeu de devinettes.
Des webhooks à l’épreuve du rejeu
Chaque événement entrant réclame une clé unique dans un registre d’idempotence avant d’être traité — une livraison réessayée ou rejouée meurt dans la couche base de données, pas dans votre automatisation.
Clés hachées, secrets à portée limitée
Les clés d’API sont stockées sous forme de hachages, et seuls le hachage et les scopes sont résolus à la porte — une ligne de base de données qui fuite ne nomme aucun espace de travail et n’ouvre rien au-delà de ses scopes.
Brouillons et confirmations sont explicites
La création de commande prend un paramètre de confirmation explicite — l’API publique confirme par défaut, les parcours du panneau peuvent préparer des brouillons — si bien que « est-ce réel ? » est un champ, pas une convention.
Mise en place
Comment ça se connecte
Émettez une clé
Créez une clé Commerce API à portée limitée dans le panneau ; révoquez-la tout aussi facilement.
Branchez un webhook
Créez un flow avec un déclencheur webhook ; signez les requêtes avec son secret.
Rappelez vers l’extérieur
Ajoutez des étapes REST là où vos systèmes doivent être mis au courant.
Mieux ensemble
Avec quoi il se combine
Flows
Les déclencheurs webhook démarrent des flows ; les étapes REST rappellent vos systèmes aux moments que vous dessinez — automatisation entrante et sortante partagent un même canevas.
Commerce
Le moteur de catalogue et de commandes derrière l’API est celui-là même qu’utilisent la boutique dans le chat et l’IA — une seule vérité de commande, quatre portes.
Votre propre boutique
Des équipes font tourner des boutiques headless sur la Commerce API dès aujourd’hui — le chemin que la page Shopify recommande honnêtement tant que le connecteur natif est en construction.
Sécurité et garanties
Les garanties ennuyeuses
HMAC sur le corps brut
La vérification des webhooks signe le corps brut de la requête avec un secret propre au déclencheur et compare en temps constant — l’analyse n’a lieu qu’après la preuve.
Les charges utiles sont des données, jamais des commandes
La charge utile d’un webhook peut désigner une personne ; elle ne peut jamais piloter les rouages d’un flow, réécrire des prompts ni invoquer des outils. La frontière entre données et instructions est architecturale, pas comportementale.
Des limites de débit à chaque porte
Les endpoints publics passent par la limitation de débit standard, et les limites de lecture sont plafonnées côté serveur — un client qui se comporte mal se dégrade lui-même, pas la plateforme.
Les petits caractères, en clair
Les limites, annoncées
Pas encore de flux global
Un flux webhook générique auquel on s’abonne pour tout n’existe pas — les événements sortants passent aujourd’hui par les étapes de flow. C’est dit ici, pour qu’aucun rendez-vous commercial n’ait à laisser entendre le contraire.
Des lectures bornées, par conception
Une lecture renvoie jusqu’à 100 lignes, avec curseur — l’API est faite pour l’intégration opérationnelle, pas pour l’export en masse. Un besoin d’export en masse se discute, il ne se contourne pas.
FAQ API et webhooks
Des réponses directes
Tout le reste est dans la FAQ, ou écrivez-nous directement.
Mieux vaut une intégration honnête qu’une intégration tapageuse.
Chaque intégration est décrite par ce qu’elle fait vraiment — sens de la synchronisation, propriété des données et limites comprises.