Modifier une règle d'imputation bancaire
PATCH/api/v1/bank_rules/:id
Modifie la règle sur place. L'activation et la désactivation passent par un PATCH de enabled plutôt que par un point de terminaison dédié. Le niveau de précédence est fixé à la création, si bien que scope et company_id envoyés dans le corps sont IGNORÉS plutôt que refusés - c'est ce qui vous permet de lire une règle et de renvoyer l'objet entier avec un seul champ modifié. workspace_id fait exception - il est lu par le contrôle d'habilitation d'espace de travail commun à toute l'API, si bien que renvoyer celui d'un espace pour lequel votre jeton n'a pas d'habilitation est refusé avec un 403. L'en-tête Idempotency-Key est accepté et facultatif.
Request
Responses
- 200
- 401
- 403
- 404
- 409
- 422
La règle telle qu'elle est désormais.
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 write que ce PATCH exige.
Aucune règle portant cet identifiant n'est atteignable par les habilitations du jeton. Une règle appartenant à un autre espace de travail répond de la même manière.
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.
La modification a été refusée. Les deux mêmes codes que la création - validation_failed pour un invariant rompu, invalid_argument pour une valeur hors du vocabulaire publié. Un corps ne portant AUCUN champ accepté est également refusé ici plutôt que répondu 200.