Zapier et Make.com

Les apps Genius Checkout Zapier et Make.com parlent aux trois mêmes endpoints REST-hook. Elles utilisent la clé API Bearer standard — pas d'OAuth séparé — et émettent les mêmes payloads documentés dans Webhooks.

Vous pouvez aussi appeler ces endpoints directement depuis tout système qui supporte le pattern REST-hook (Zapier, Make, Pipedream, n8n, code personnalisé).

Comment Zapier / Make consomment les endpoints

Un trigger REST-hook a trois parties :

1. Subscribe — Zapier fait POST avec l'URL cible de l'utilisateur quand le Zap est activé.
2. Recevoir les événements — Genius Checkout pousse des webhooks signés à cette URL.
3. Unsubscribe — Zapier fait DELETE quand le Zap est désactivé ou supprimé.

Pour le setup initial, Zapier montre une UI "Test trigger" qui appelle /zapier/sample-payments pour que l'utilisateur puisse mapper les champs sans avoir besoin d'une transaction réelle. Le module "Watch events" de Make.com fonctionne pareil.

Subscribe

POST /api/v1/zapier/subscriptions

Champ	Type	Requis	Description
target_url	string	Oui	URL HTTPS fournie par Zapier / Make. Nous y poussons les événements.
event	string	Oui	Un seul événement auquel s'abonner. Voir la liste ci-dessous.

Événements supportés

• payment.created
• payment.completed
• payment.failed
• payment.refunded
• subscription.charged
• subscription.cancelled
• checkout_session.completed

Réponse (201)

{
  "id": "whe_zap_abcdef123456",
  "event": "payment.completed",
  "target_url": "https://hooks.zapier.com/hooks/catch/123/abc/"
}

L'id est le handle d'abonnement que Zapier / Make stockent et présentent à l'endpoint d'unsubscribe. En interne, chaque abonnement est modélisé comme un webhook endpoint GC de première classe, donc les marchands voient aussi le câblage dans Dashboard → Webhooks.

Unsubscribe

DELETE /api/v1/zapier/subscriptions/{id}

Renvoie { "ok": true } en cas de succès. 404 si l'abonnement n'existe pas pour le marchand authentifié.

Sample payments (pour l'UX "Test trigger")

GET /api/v1/zapier/sample-payments

Renvoie jusqu'à 3 paiements récents du marchand, dans la même forme que le payload de webhook réel (id, receipt_number, amount, currency, status, card_brand, card_last4, mode, created_at, metadata).

Si le marchand n'a pas encore de transactions, nous renvoyons un échantillon synthétique pour que l'UX Zap-builder ne se bloque jamais sur un compte tout neuf.

curl -H "Authorization: Bearer $GC_API_KEY" \
  https://app.geniuscheckout.com/api/v1/zapier/sample-payments

Mettre le tout ensemble

// Node — abonner Zapier aux événements payment.completed
const sub = await fetch('https://app.geniuscheckout.com/api/v1/zapier/subscriptions', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.GC_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    target_url: 'https://hooks.zapier.com/hooks/catch/123/abc/',
    event: 'payment.completed',
  }),
}).then(r => r.json())

// Plus tard, quand le Zap est désactivé :
await fetch(`https://app.geniuscheckout.com/api/v1/zapier/subscriptions/${sub.id}`, {
  method: 'DELETE',
  headers: { Authorization: `Bearer ${process.env.GC_API_KEY}` },
})

Payload de webhook et signature

Les événements livrés à l'URL cible Zapier / Make utilisent l'enveloppe webhook GC standard et la signature HMAC-SHA256. Voir Webhooks → Vérification de signature. Les inspecteurs de requêtes Zapier et Make.com exposent les en-têtes X-GC-Signature et X-GC-Timestamp si vous devez déboguer une livraison.

Suite

• Webhooks — forme du payload, en-tête de signature, fenêtre de rejeu
• Limites de débit — Zapier subscribe/unsubscribe tombe dans le tier writes