Retrieve a bank statement
GET/api/v1/bank_statements/:id
Returns one statement. This is the poll target after an upload or a retry, and state is the field to read. started_at and finished_at are the extraction's own clocks now: a processing file publishes a start and no end, and both stay null on a file no pass has claimed.
A pending that does not move is not necessarily working. pending means stored and not yet reviewable, and a file sits there whether its extraction was queued, was refused at upload (meta.unqueued_statement_ids on the 202), or was never going to run because the company has AI extraction switched off. processing is the state that does mean work is running. So bound your polling: a statement that stays pending is one to re-drive with POST /bank_statements/{id}/retry, not one to keep waiting on - when its retryable is true. A pending with retryable false belongs to a company with AI extraction switched off: the retry is refused with operation_failed until the setting is turned on in Scribee.
Request
Responses
- 200
- 401
- 403
- 404
The bank statement.
The request carries no bearer token, or one that is invalid or expired. doorkeeper_authorize! is the first gate of the chain, so this is answered before the workspace, the company, the feature flag and the statement are ever resolved - and before any Idempotency-Key is claimed.
The token may not perform this call. On a GET the scope is read, which every token holds, so what answers here is one of the other three gates of the shared chain: the workspace GRANT, the bank_reconciliation FEATURE FLAG, or the action's own Pundit check. All render the same body, so message is what distinguishes them. The example below is refused by the flag.
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.