Preview what a bank rule would do
POST/api/v1/bank_rules/:id/preview
Simulates the rule against real operations AND WRITES NOTHING - no allocation, no payment, no accounting entry. That is why it requires only read: forcing you to hold write in order to inspect a rule would be backwards. Each row says whether the rule would determine that operation's projection, the lines it would produce, and - through overridden_by - whether a higher-precedence source already wins it.
Request
Responses
- 200
- 400
- 401
- 403
- 404
- 409
One row per operation examined, newest operation date first.
page is past the last page of a non-empty set, or is not a positive integer. Stop at meta.total_pages: on a non-empty collection the page after the last one is this refusal, not an empty page. An EMPTY collection answers 200 with an empty data on every page instead.
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 record are ever resolved - and before any Idempotency-Key is claimed.
The token does not hold the read scope this preview requires. It is a POST, but it writes nothing, so read is the scope it takes - and write alone is not enough.
No rule with this id is reachable by the token's grants.
You sent the optional Idempotency-Key and a call bearing it is still in flight - idempotency_request_in_progress. Nothing was written by THIS call. Once the first completes, the same key replays its stored response rather than conflicting.