Summary
Please add support for filtering transactions by a last-modified timestamp (e.g. filter[updatedSince]), so that incremental syncs can pick up retroactive changes to existing transactions.
Problem
The /transactions endpoint currently supports filter[since] and filter[until], which operate on createdAt. This works well for fetching new transactions, but it misses changes made to transactions that were created before the sync window - most notably:
- Re-categorising a transaction days or weeks after it settled
- Adding/removing tags
- A transaction moving from
HELD to SETTLED (where the created time doesn't change)
Because these edits don't affect createdAt, an incremental sync that only queries recent transactions will never see them. The only reliable workaround today is periodically re-fetching the full transaction history and diffing it locally, which is slow and wasteful for both clients and your servers.
Proposed solution
- Expose an
updatedAt (or modifiedAt) attribute on the transaction resource, bumped whenever any user- or system-driven change occurs (category, tags, status, notes, etc.).
- Add a corresponding query parameter, e.g.
GET /transactions?filter[updatedSince]=2026-07-01T00:00:00+10:00, returning all transactions modified at or after that time regardless of when they were created.
Alternatives considered
- Webhooks:
TRANSACTION_SETTLED events exist, but there's no event for category/tag edits, and webhook delivery isn't a substitute for a re-syncable filter when rebuilding state.
- Full re-fetch + local diff: works, but doesn't scale for accounts with long histories and defeats the purpose of incremental syncing.
Use case
Any tool doing ongoing sync into a local store (budgeting apps, spreadsheets, data warehouses) needs this to keep category data accurate, since re-categorising past transactions is a core Up feature.
Summary
Please add support for filtering transactions by a last-modified timestamp (e.g.
filter[updatedSince]), so that incremental syncs can pick up retroactive changes to existing transactions.Problem
The
/transactionsendpoint currently supportsfilter[since]andfilter[until], which operate oncreatedAt. This works well for fetching new transactions, but it misses changes made to transactions that were created before the sync window - most notably:HELDtoSETTLED(where the created time doesn't change)Because these edits don't affect
createdAt, an incremental sync that only queries recent transactions will never see them. The only reliable workaround today is periodically re-fetching the full transaction history and diffing it locally, which is slow and wasteful for both clients and your servers.Proposed solution
updatedAt(ormodifiedAt) attribute on the transaction resource, bumped whenever any user- or system-driven change occurs (category, tags, status, notes, etc.).GET /transactions?filter[updatedSince]=2026-07-01T00:00:00+10:00, returning all transactions modified at or after that time regardless of when they were created.Alternatives considered
TRANSACTION_SETTLEDevents exist, but there's no event for category/tag edits, and webhook delivery isn't a substitute for a re-syncable filter when rebuilding state.Use case
Any tool doing ongoing sync into a local store (budgeting apps, spreadsheets, data warehouses) needs this to keep category data accurate, since re-categorising past transactions is a core Up feature.