Simuler ce qu'une règle d'imputation ferait
POST/api/v1/bank_rules/:id/preview
Confronte la règle à de VRAIES opérations SANS RIEN ÉCRIRE - ni rapprochement, ni paiement, ni écriture comptable. C'est pour cela qu'elle ne demande que read : vous obliger à détenir write pour inspecter une règle serait à l'envers. Chaque ligne dit si la règle déterminerait la projection de cette opération, les lignes qu'elle produirait, et - par overridden_by - si une source de précédence supérieure l'emporte déjà.
Request
Responses
- 200
- 400
- 401
- 403
- 404
- 409
Une ligne par opération examinée, de la date d'opération la plus récente à la plus ancienne.
page dépasse la dernière page d'un ensemble non vide, ou n'est pas un entier positif. Arrêtez-vous à meta.total_pages : sur une collection non vide, la page qui suit la dernière est ce refus, et non une page vide. Une collection VIDE répond quant à elle 200 avec un data vide sur chaque page.
La requête ne porte aucun jeton bearer, ou en porte un invalide ou expiré. doorkeeper_authorize! est le premier contrôle de la chaîne, si bien que cette réponse arrive avant que l'espace de travail, l'entreprise, l'indicateur de fonctionnalité et l'enregistrement ne soient résolus - et avant qu'aucune clé Idempotency-Key ne soit réservée.
Le jeton ne détient pas la portée read que cette simulation exige. C'est un POST, mais il n'écrit rien, si bien que read est la portée qu'il prend - et write seule ne suffit pas.
Aucune règle portant cet identifiant n'est atteignable par les habilitations du jeton.
Vous avez envoyé la clé facultative Idempotency-Key et un appel la portant est encore en cours - idempotency_request_in_progress. CET appel n'a rien écrit. Dès que le premier se termine, la même clé rejoue sa réponse enregistrée au lieu d'entrer en conflit.