Webhooks entrants

Inklura reçoit les webhooks de fournisseurs externes sur des routes fixes sous https://manage.inklura.fr/api/webhooks/*. Chaque récepteur est propre à son fournisseur : vous configurez le côté fournisseur en connectant l'intégration.

Il n'existe pas d'API d'abonnement aux webhooks pour les événements de la plateforme : vous ne pouvez pas enregistrer votre propre URL pour qu'Inklura l'appelle. Pour envoyer des événements depuis une application vers un système externe, voir Envois sortants.

Fonctionnement d'un récepteur

1. Le fournisseur envoie une requête POST à la route du récepteur.
2. Le récepteur authentifie la requête selon ce que prévoit son intégration (voir plus bas pour Stripe, WordPress et PrestaShop).
3. L'événement est traité, tout de suite ou via une file en arrière-plan selon le récepteur.

fournisseur ──POST──> /api/webhooks/<fournisseur> ──authentification──> traitement

Paiements

Stripe

Vérification : l'en-tête Stripe-Signature, contrôlé avec le secret de signature du point de terminaison configuré dans Stripe (la vérification standard de Stripe). Une signature absente ou invalide renvoie 400 et l'événement n'est pas traité.

PayPal, crypto et paiements génériques

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

Commerce

WordPress

/api/webhooks/wordpress reçoit les événements d'un site WordPress connecté : articles, pages, médias, catégories, étiquettes, menus, produits et variations (y compris les changements de stock), commandes, clients, codes promo, et prospects issus de formulaires (lead.submitted). Le corps JSON porte le nom de l'événement dans event (par exemple post.updated) et l'entité dans id et data.

Authentification : la clé d'accès et le secret HMAC de la connexion WordPress du site. Chaque requête porte ces en-têtes :

Si vous envoyez ces événements depuis votre propre code, signez chaque requête ainsi :

1. Concaténez, sans séparateur : la valeur de x-cmgr-timestamp, la méthode POST, le chemin /api/webhooks/wordpress et le corps brut de la requête, tel qu'il est envoyé.
2. Calculez un HMAC-SHA256 de cette chaîne (UTF-8) avec le secret HMAC de la connexion.
3. Envoyez le résultat en hexadécimal minuscule dans x-cmgr-signature.

import { createHmac } from "node:crypto";

const body = JSON.stringify(event);
const timestamp = String(Math.floor(Date.now() / 1000));
const signature = createHmac("sha256", HMAC_SECRET)
  .update(timestamp + "POST" + "/api/webhooks/wordpress" + body, "utf8")
  .digest("hex");

await fetch("https://manage.inklura.fr/api/webhooks/wordpress", {
  method: "POST",
  headers: {
    "content-type": "application/json",
    "x-cmgr-tenant-id": TENANT_ID,
    "x-cmgr-site-id": SITE_ID,
    "x-cmgr-key": ACCESS_KEY,
    "x-cmgr-timestamp": timestamp,
    "x-cmgr-nonce": crypto.randomUUID(),
    "x-cmgr-signature": signature,
  },
  body,
});

Quand la connexion a un secret HMAC, chaque événement doit porter une signature valide et un horodatage à moins de 5 minutes de l'heure du serveur (dans un sens comme dans l'autre) ; une requête rejouée plus tard est refusée.

Un nom d'événement inconnu est accepté (200) mais ignoré. Une requête GET sur la même route renvoie la liste des événements pris en charge dans supportedEvents.

PrestaShop

/api/webhooks/prestashop/<entité> reçoit les événements du module connecteur PrestaShop, par type d'entité : customers, products ou orders. Le corps JSON porte un tableau events ; chaque événement a un id, une action (create, update ou delete), et peut porter entity, data et timestamp.

{
  "events": [
    { "entity": "products", "action": "update", "id": 42, "data": { }, "timestamp": "2026-10-10T08:00:00Z" }
  ]
}

Authentification : le module envoie le secret de webhook de votre site (affiché dans les réglages de l'intégration PrestaShop de la console) tel quel, sans calcul HMAC, dans l'en-tête X-Webhook-Signature. Le récepteur s'en sert pour retrouver votre site.

Un événement sans id ou sans action n'interrompt pas le lot : il apparaît en échec dans results.

Autres boutiques en ligne

• /api/webhooks/woocommerce

Fournisseurs d'e-mail

Événements de rebond, d'ouverture, de plainte (et similaires) des fournisseurs d'e-mail, une route par fournisseur :

resend · mailgun · sendgrid · postmark · ses · sparkpost · sendinblue · socketlabs · mandrill · pepipost

Livraison

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

Réseaux sociaux

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

Autres

• /api/webhooks/twilio/status : statut de livraison SMS et voix
• /api/webhooks/yousign : événements de signature électronique
• /api/webhooks/shipping/tracking : suivi des colis par les transporteurs
• /api/webhooks/google/ucp : statut des commandes et notifications de Google Merchant Center
• /api/webhooks/calendar : notifications des agendas connectés (Google, Outlook, Apple)

Pas d'abonnement en libre-service

Inklura ne permet pas d'abonner une URL de votre choix aux événements de la plateforme. Les récepteurs ci-dessus sont les intégrations fournisseurs de la plateforme. Pour réagir à un événement, faites-le depuis votre application : loaders et actions, un queue worker ou une tâche planifiée.

Envois sortants

L'étape WEBHOOK des journeys

Le moteur de journeys propose un type d'étape WEBHOOK, mais il n'émet aujourd'hui aucune requête HTTP. Ne construisez rien qui suppose le contraire.

Envoyer depuis votre application avec un secret partagé

Pour pousser des données vers le système d'un client, votre application envoie elle-même une requête POST à la destination, avec un en-tête contenant un secret partagé que la destination vérifie.

Exemple : une application qui publie un menu du jour sur le site WordPress d'un commerçant. Le secret propre à chaque site est rangé dans le KV.

import { createSdk } from "@bext-stack/framework/sdk";

const sdk = createSdk("<app-id>");

await fetch(`https://${host}/wp-json/mon-plugin/v1/menu-du-jour`, {
  method: "POST",
  headers: {
    "X-App-Secret": (await sdk.kv.get<string>(`push-secret:${host}`)) ?? "",
    "content-type": "application/json",
  },
  body: JSON.stringify(payload),
});

Côté destination, comparez l'en-tête au secret attendu avant d'accepter la requête.

Voir aussi

• Vue d'ensemble des événements
• Queue Workers
• Journeys marketing