Relancer l'extraction d'un relevé

POST 
/api/v1/bank_statements/:id/retry

Relance l'extraction sur un fichier dont la première tentative n'a pas abouti. Lisez retryable sur le relevé avant d'appeler : l'indication et ce point de terminaison lisent la même règle. Le 202 retourne le relevé remis à pending, l'erreur précédente effacée.

Request

Responses

202

The extraction was re-enqueued. The statement is back to pending.

401

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.

403

Le jeton n'est pas autorisé à effectuer cet appel, et trois contrôles de la chaîne partagée y répondent de manière identique : le SCOPE OAuth déduit du verbe HTTP (celui-ci exige write), l'HABILITATION que l'application détient sur l'espace de travail, et le DRAPEAU DE FONCTIONNALITÉ bank_reconciliation. Le contrôle Pundit propre à l'action en est un quatrième. Les quatre rendent le même corps, message est donc le seul élément qui les distingue ; dans tous les cas, rien n'a été effectué. L'exemple ci-dessous est refusé sur le scope.

404

Aucun relevé portant cet identifiant n'est atteignable par les habilitations du jeton. Un relevé appartenant à un autre espace de travail répond de la même manière, si bien que la réponse ne permet pas d'en sonder l'existence.

409

This Idempotency-Key is claimed and its outcome is not replayable - idempotency_request_in_progress. Nothing was enqueued by THIS call. That is USUALLY a first call still running, but it is also what you get when a first call DID enqueue the extraction and then failed while rendering its response - so it does not mean the retry never happened, and the two are not distinguishable from the outside today. Do not retry in a loop: read the statement with GET /bank_statements/{id} and let its state tell you whether an extraction is under way (processing) or still owed (pending). The key frees itself 24 hours after first receipt. A retry carries no body, so its fingerprint can never differ from the first call's - idempotency_key_reuse is unreachable here, and a completed first call replays its stored 202 rather than conflicting.

422

Either the statement is in a state that forbids a retry - it is archived, or the extraction already completed, and statement_not_reviewable names the state, so the remedy is to read the statement rather than to call again - or the Idempotency-Key header is missing or outside the accepted 1-255 characters, which is validation_failed with details.idempotency_key. The first refusal is about the statement and carries no details; the second is about the request and always does, so details is what tells them apart. Nothing was enqueued in either case.

A THIRD refusal reports the platform rather than your request: operation_failed, with no details, means the extraction could not be queued. The statement has been reset and is back to pending, so nothing is being read yet and this same call is the remedy - retry it. It is deliberately not statement_not_reviewable: the statement's state is fine, so waiting for it to change would never end. operation_failed is also the answer when the company has AI extraction turned off, which retryable already reports as false: the statement is left exactly as it was and nothing was queued, so turn the setting on before calling again.