Révoquer un secret de signature
Révoquer le dernier secret actif **coupe toutes les notifications** : sans secret actif, rien n'est émis. Créez le remplaçant avant de révoquer.
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
Path Parameters
Identifiant du secret (whsec_…), tel que renvoyé à la création et par le listing. Ce n'est pas la clé de signature.
1 <= lengthResponse Body
application/json
application/json
application/json
application/json
application/json
curl -X DELETE "https://example.com/v1/webhook-secrets/string"{ "success": true, "message": "string"}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 ».
Notification de transaction Webhook
Émise à chaque changement de statut, et à la mise à disposition d'une `authorizationUrl` pour les corridors `redirect_url`. Postée en `application/json` sur le `webhookUrl` de la transaction. Timeout 30 s par tentative, aucune redirection suivie, et **jusqu'à 6 tentatives** (immédiate, +30 s, +2 min, +10 min, +1 h, +6 h) tant que la réponse n'est pas 2xx. Chaque tentative est journalisée dans `notifications[]` sur `GET /v1/transactions/by-id/{transactionId}`, et une notification peut être renvoyée à la demande — cf. [réconciliation](/docs/reconciliation).