Scénarios d’utilisation

1) Intégration d’un échange sur le site

Objectif

ajouter sur le site un formulaire d’échange avec sélection des devises/réseaux, validation d’adresse et création d’une commande.

Endpoints

• v2 : POST /api/v2/instruments/public/validate-address, POST /api/v2/instruments/public/one, GET /api/v2/instruments/public, POST /api/v2/orders/public/create, POST /api/v2/orders/public/set-email
• v1 (en complément si nécessaire pour statuts/vitrine) : GET /api/v1/instruments/public, GET /api/v1/instruments/public/one, POST /api/v1/instruments/public/validate-address

Flux

1. Charger le répertoire des instruments actifs (devise + réseau) pour construire la liste « Je donne / Je reçois ».
2. En fonction du choix de l’utilisateur, demander les détails de l’instrument « je reçois » (précision, memo/tag, limites).
3. Valider l’adresse de destination via validate-address.
4. Créer la commande : POST /api/v2/orders/public/create (v2 recommandé). Sauvegarder orderId et afficher depositAddress à l’utilisateur.
5. (Optionnel) ajouter un email à la commande : POST /api/v2/orders/public/set-email — pour les notifications à l’utilisateur.
6. Afficher un écran avec les instructions de paiement vers depositAddress et un compte à rebours.

2) Récupération et affichage des taux

Objectif

afficher à l’utilisateur les taux actuels pour la paire sélectionnée.

Endpoints

• v1 : GET /api/v1/rates/public/one — taux public au format JSON.

Flux

1. Lorsqu’un utilisateur choisit une paire — demander le taux public via rates/public/one.
2. Afficher le taux, les montants minimum/maximum (s’ils sont renvoyés), ainsi que l’heure de validité.
3. (Optionnel) appliquer un « markup » visuel au taux affiché sur la vitrine (voir scénario 4), mais ne pas utiliser ce taux ajusté pour créer réellement une commande dans une autre version de l’API.

3) Création et suivi des commandes

Objectif

créer une commande et fournir à l’utilisateur un statut d’exécution clair.

Endpoints

• v2 : POST /api/v2/orders/public/create, POST /api/v2/orders/public/set-email
• v1 : POST /api/v1/orders/public/create, GET /api/v1/orders/public-info, GET /api/v1/orders/public/latest, POST /api/v1/orders/public/accept-rate-mode-change, POST /api/v1/orders/public/request-refund, GET /api/v1/orders/order-refund-info

Flux (v2 — recommandé pour la création)

1. Valider les saisies et l’adresse de destination.
2. Créer la commande : v2/orders/public/create → obtenir orderId, depositAddress.
3. Proposer « Ajouter un email » : v2/orders/public/set-email.
4. Afficher à l’utilisateur les instructions pour effectuer le dépôt.

Suivi du statut (vitrine et espace utilisateur)

• Vitrine « derniers échanges » : GET /api/v1/orders/public/latest.
• Détails d’une commande spécifique : GET /api/v1/orders/public-info?orderId=...&destinationAddress=... — tableaux deposits/withdrawals, confirmations, txId, networkFee.
• Changement du mode de taux à la demande : POST /api/v1/orders/public/accept-rate-mode-change.
• Remboursements : POST /api/v1/orders/public/request-refund → détails via GET /api/v1/orders/order-refund-info.

4) Vérification du statut des transactions

Objectif

donner à l’utilisateur de la transparence sur l’avancement des dépôts et des retraits.

Endpoints

• v1 : GET /api/v1/orders/public-info, GET /api/v1/orders/order-refund-info

Flux

1. Interroger périodiquement public-info avec orderId et destinationAddress.
2. Dans le bloc deposits[0], analyser isPending, confirmations, txId, depositAddress.
3. Lorsque le dépôt est confirmé — afficher les informations de retrait à partir du tableau withdrawals (montant, networkFee, txId).
4. En cas de remboursement — récupérer les détails via order-refund-info et afficher le statut « Remboursement en cours/terminé ».