Supprimer un relevé bancaire
DELETE/api/v1/bank_statements/:id
Supprime le relevé et le fichier stocké. Autorisé uniquement AVANT l'enregistrement des opérations, et c'est committed qui porte cette frontière - PAS la réconciliation. committed passe à true dès que l'extraction enregistre des opérations - les LIGNES elles-mêmes, qui sont écrites avant operations_count -, donc lisez-le avant d'appeler : un relevé qui rapporte committed: true est refusé quel que soit son state. En pratique, ce point de terminaison annule un import qui n'a rien produit - un relevé encore à committed: false, dans n'importe quel état. Un relevé archived est refusé aussi. Le corps de la réponse est le relevé tel qu'il était au moment où vous en avez demandé la suppression - sérialisé avant la suppression, parce qu'ensuite son fichier n'existe plus pour être décrit.
Request
Responses
- 200
- 401
- 403
- 404
- 409
- 422
The statement was deleted, and is returned as it last stood.
La requête ne porte aucun jeton bearer, ou en porte un qui est invalide ou expiré. doorkeeper_authorize! est le premier contrôle de la chaîne, si bien que la réponse est rendue avant que l'espace de travail, l'entreprise, le drapeau de fonctionnalité et le relevé ne soient résolus - et avant qu'une Idempotency-Key ne soit revendiquée.
The token may not perform this call, and three gates of the shared chain answer it identically: the OAuth SCOPE derived from the HTTP verb (this one needs destroy, with write as the alternative), the workspace GRANT the application holds, and the bank_reconciliation FEATURE FLAG. The action's own Pundit check is a fourth. All four render the same body, so message is what distinguishes them; nothing was performed in any case. The example below is refused on the scope.
No statement with this id is reachable by the token's grants. One belonging to another workspace answers the same way, so the response cannot be used to probe for one. A second KEYLESS delete lands here too - the row is already gone, which is the convergence the header exists to turn into a replayed 200 instead.
You sent the optional Idempotency-Key and a call bearing it is still in flight - idempotency_request_in_progress. Nothing was deleted by THIS call. A DELETE carries no body, so its fingerprint can never differ from the first call's: idempotency_key_reuse is unreachable here, and once the first call completes the same key replays its stored 200 rather than conflicting.
The delete was refused, and details is what tells the two refusals apart.
Without details - the statement may not be deleted, and statement_not_reviewable covers both reasons with message naming which. EITHER the statement is past commit - committed: true, meaning its extraction has already persisted operations - and that one is PERMANENT: the statement will never become deletable, so do not poll and do not retry. Use PATCH /lines to correct it, or leave it in place. OR it is archived, which is equally terminal - an archived file was stored, never extracted. Reconciliation is NOT the boundary: a completed statement carrying extracted lines nobody has reconciled yet is already past commit.
With details - you sent the optional Idempotency-Key and its length is outside the accepted 1-255 characters, which is validation_failed with details.idempotency_key. Nothing was deleted: the key is checked in front of the action.