Bulk update transactions
Accepts one asynchronous all-or-nothing operation for at most 5,000 transactions. Supply exactly one non-empty selector and a non-empty updates object. Filters combine with AND and select pre-update values. Split parents and all split-derived records are excluded from filters; explicit split IDs fail the job. Transfer eligibility follows existing per-field rules. No matches succeeds with zero updates. Targets freeze at processing start; relevant later edits fail the job. accounting_shift moves each effective accounting date by calendar months, clamping once to the destination month. Omission leaves a field unchanged; null clears department/spread or restores the original accounting date. Requires current API access: Manage and Transactions: Manage, an active actor and company membership, and an eligible company subscription/lifecycle. Those permissions are checked again during execution. No identities are created by submission.
Idempotency keys are scoped to company and submitting user. Identical normalized bodies replay the original queued 202 response; a changed body returns 409. Object key order is ignored; array order is preserved; null and omission differ. Key strings are case-sensitive and are not trimmed or normalized. Whitespace-only keys are rejected. The operation, company and actor define the key scope; a different API key for the same actor/company shares that scope. Keys and results remain for 30 days after terminal completion; active jobs do not expire. After expiry, a new submission can apply another shift. Retrieve the known job to learn its current outcome. The 202 body always contains the stored queued acceptance (matched_count null, updated_count 0, empty errors), even if execution already completed before the response or replay. No response does not imply rejection: retry with the same key and identical body while retained. After expiry the same key creates new work and can apply a relative shift again.
The only public filters are merchant, category_id, account_id, card_id, start_date, end_date, status, transaction_type and categorized. Unknown fields, empty selectors, invalid IDs/dates/enums, duplicate IDs, malformed types, inverted date ranges, and simultaneous selectors are rejected with 400 invalid_request. Explicit selection permits 1–5,000 unique txn_ IDs; 5,001 are rejected before acceptance. Filter selection is asynchronous, unpaginated and fails atomically above 5,000 matches. Unknown or inaccessible account/card references receive the same 404 resource_missing; an incompatible known account/card pair is 400 invalid_request. Missing/foreign transaction IDs and business eligibility errors are job failures discovered during execution.
Success and replay consume API requests, as does polling. Existing per-minute and monthly limits apply. On 429 rate_limit_exceeded, wait Retry-After then retry the identical body/key with backoff. On monthly_limit_exceeded, stop short-term retries; no Retry-After is sent. Fix 400, 401 or 403 before retrying. A 409 idempotency_key_conflict means the key already identifies a different body; poll the original job rather than changing the key to guess whether work ran.
Authorizations
API key prefixed with finta_
Headers
Nonblank string of 1–255 characters. Whitespace-only and oversized keys return 400 invalid_request with param Idempotency-Key.
1 - 255\SBody
- Option 1
- Option 2
Exactly one non-empty selector and a non-empty updates object; no unknown top-level keys.
Exactly these nine filters are public; combine supplied fields with AND against pre-update values. Selects all matches without pagination. start_date and end_date are inclusive and end_date must not precede start_date. Explicit null is invalid for filters.
Omitted fields are unchanged. Null clears department/spread or restores the original date. merchant and category_id cannot be null. accounting_date and accounting_shift cannot coexist, including a null date. Shared eligibility restrictions apply atomically at execution.
Response
Original queued acceptance, including on replay after success or failure. Retrieve Location for the current outcome.
^job_[A-Za-z0-9]+$job bulk_update_transactions queued awaits execution; processing has a frozen selection; success has committed edits and durable reporting refresh intent; failed has no committed edits. Reporting refresh can finish after success.
queued, processing, success, failed Null until selection succeeds, then the number of frozen targets. A successful empty selection is zero.
x >= 0Distinct transactions actually changed, including assignment provenance, counted once each. Failed jobs always report zero.
x >= 0