Lister les secrets de signature actifs
Les secrets actifs de votre organisation, du plus récent au plus ancien. La clé `whsec_…` elle-même n'est jamais renvoyée : seul son `secretId` et sa date de création. Le secret qui signe effectivement est le **plus ancien** de cette liste.
Clé d'API de l'organisation, envoyée en Authorization: Bearer sk_live_… (sk_test_… sur le serveur Sandbox). Il n'existe aucun header X-API-Key.
In: header
Response Body
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/v1/webhook-secrets"{ "success": true, "data": { "secrets": [ { "secretId": "string", "createdAt": "string" } ] }}Renvoyer la notification webhook d'une transaction POST
Rattrapage en libre-service après épuisement de l'échelle de retries automatique (jusqu'à 6 tentatives, cf. [réconciliation](/docs/reconciliation)) : programme une nouvelle notification — avec sa propre chaîne de tentatives, ce n'est pas un envoi synchrone — consultable ensuite dans `notifications[]` sur `GET /v1/transactions/by-id/{transactionId}`. Refusé tant que la transaction n'est pas dans un état terminal (`completed`, `failed`, `cancelled`). Plafonné à 3 requêtes par minute et par transaction.
Créer un secret de signature POST
Sans secret **actif**, aucune notification n'est émise : la tentative est journalisée en `SKIPPED_NO_SECRET` et rejouée, mais si la chaîne s'épuise avant qu'un secret existe, l'issue ne vous sera pas poussée. Le secret n'est affiché qu'à cette réponse. Créer un secret n'invalide pas les précédents, et ne bascule pas non plus la signature : c'est le **plus ancien** secret actif qui signe, jusqu'à sa révocation. La rotation est donc « créer, déployer le nouveau vérificateur, révoquer l'ancien ».