Webhooks entrants

Inklura reçoit des webhooks de fournisseurs externes sur un ensemble de routes réceptrices fixes sous https://manage.inklura.fr/api/webhooks/* dans l'application company-manager. Chaque récepteur vérifie la signature/le secret du fournisseur puis met en file l'événement pour traitement.

Il n'existe aucune API d'abonnement à des webhooks en libre-service — vous ne pouvez pas enregistrer votre propre URL pour qu'Inklura l'appelle. Les récepteurs ci-dessous sont les intégrations propres à la plateforme. Pour pousser des événements hors d'une application, voir Sortants.

Fonctionnement d'un récepteur

Chaque récepteur suit la même forme :

  1. Le fournisseur envoie une requête POST à la route réceptrice.
  2. Le récepteur vérifie la requête — un en-tête de signature du fournisseur ou un secret partagé.
  3. En cas de succès il alimente la file webhook (une file BullMQ/Redis du company-manager ; voir Vue d'ensemble des événements).
provider ──POST──> /api/webhooks/<provider> ──verify──> enqueue(webhook) ──> worker

La vérification est propre à chaque fournisseur — une signature erronée ou manquante est rejetée avant toute mise en file.

Paiements

Stripe

Route Notes
/api/webhooks/stripe Événements Stripe principaux
/api/webhooks/stripe/magazine Déclenche aussi le journey ORDER_MINTED
/api/webhooks/stripe/classified-ads Paiements des petites annonces
/api/webhooks/stripe-subscriptions Cycle de vie des abonnements

Auth : l'en-tête Stripe-Signature, vérifié avec STRIPE_WEBHOOK_SECRET via stripe.webhooks.constructEvent.

PayPal / crypto / générique

  • /api/webhooks/paypal
  • /api/webhooks/payments
  • /api/webhooks/cryptocurrency

Commerce

Push WordPress

/api/webhooks/wordpress — reçoit les événements de post / page / média / produit / commande / client / coupon poussés depuis un site WordPress connecté.

Auth : un secret partagé HMAC-SHA256. La requête transporte ces en-têtes :

En-tête Signification
x-cmgr-key Identifiant de clé
x-cmgr-timestamp Horodatage de la requête
x-cmgr-nonce Nonce
x-cmgr-signature hmac_sha256(secret, payload), encodé en hexadécimal
x-cmgr-tenant-id Portée du tenant
x-cmgr-site-id Portée du site

La signature est calculée comme hmac_sha256(secret, payload) et comparée sous forme de chaîne hexadécimale.

Boutiques en ligne

  • /api/webhooks/woocommerce
  • /api/webhooks/prestashop/[entity] — événements PrestaShop par entité
  • /api/webhooks/shipping/tracking

Fournisseurs d'e-mail

Événements de rebond / ouverture / plainte (et similaires) provenant d'un éventail de fournisseurs d'e-mail. Chacun vérifie la signature de ce fournisseur, puis met en file :

resend (en-têtes svix) · mailgun · sendgrid · postmark · ses · sparkpost · sendinblue · socketlabs · mandrill · pepipost

Le modèle est identique pour tous : vérifier la signature du fournisseur → mettre en file.

Livraison

  • /api/webhooks/ubereats
  • /api/webhooks/deliveroo

Réseaux sociaux

Événements de plateforme (/api/webhooks/<network>) pour : facebook · instagram · linkedin · tiktok · twitter · youtube

Autres

  • /api/webhooks/twilio/status — statut de livraison SMS/voix
  • /api/webhooks/google/ucp
  • /api/webhooks/calendar

Aucune API d'abonnement en libre-service

Pour être explicite : Inklura n'offre pas de moyen d'abonner une URL arbitraire aux événements de la plateforme. Les récepteurs ci-dessus sont les propres intégrations fournisseurs de la plateforme, chacune câblée à un schéma de vérification spécifique et à la file interne webhook. Si vous devez réagir à quelque chose, faites-le depuis l'intérieur de votre application (loaders/actions, un queue worker ou une tâche planifiée).

Sortants

Deux choses existent ici, et il est important d'être précis à leur sujet.

Étape WEBHOOK de journey — un stub en v1

Le moteur de journeys possède un type d'étape WEBHOOK, mais en v1 c'est un stub non fonctionnel : il n'émet pas de requête HTTP sortante. Ne construisez rien dessus en supposant que ce sont des webhooks sortants qui fonctionnent.

Attention

L'étape WEBHOOK de journey n'envoie rien en v1. Considérez-la comme non encore implémentée.

Push d'application → externe par secret partagé

Certains outils PRISM poussent bien des données vers le système propre d'un tenant, mais ils le font sous forme d'intégrations sur mesure, pas via un service de webhook générique. Le modèle est une simple requête HTTP POST portant un en-tête de secret partagé que le système récepteur vérifie.

Exemple : le publieur de « plat-du-jour » d'e-Repas envoie une requête POST au WordPress propre du magasin avec l'en-tête X-Erepas-Secret, dont la valeur par magasin est lue depuis le KV à pdj-secret:<host>.

await fetch(`https://${host}/wp-json/erepas/v1/pdj`, {
  method: "POST",
  headers: {
    "X-Erepas-Secret": await sdk.kv.get(`pdj-secret:${host}`),
    "content-type": "application/json",
  },
  body: JSON.stringify(payload),
});

C'est le modèle à copier pour un push application→externe : votre application envoie une requête POST directement à la destination et s'authentifie avec un secret que la destination connaît déjà.

Voir aussi