Renvoyer la notification webhook d'une transaction
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.
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 technique az54 de la transaction (champ id, pas votre order_id). Renvoyé par POST /v1/pay-in, POST /v1/pay-out et cette même liste.
uuidResponse Body
application/json
application/json
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/v1/transactions/by-id/497f6eca-6276-4993-bfeb-53cbbbba6f08/resend-callback"{ "success": true, "data": { "message": "string" }}Consulter une transaction par son identifiant GET
Rattrapage recommandé après une notification manquée : contrairement au reçu public (`GET /v1/transactions/{orderId}`), scopé à votre organisation et porte le détail complet (frais, `netAmount`, cause d'échec, journal des notifications webhook). Un `id` d'une autre organisation rend `404`, au même titre qu'un `id` inexistant.
Lister les secrets de signature actifs GET
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.