Feature request: Add an updatedAt filter on transactions to support incremental syncs #179

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

1. Expose an updatedAt (or modifiedAt) attribute on the transaction resource, bumped whenever any user- or system-driven change occurs (category, tags, status, notes, etc.).
2. 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.