Expose Pot Transaction Data via Public API (Parity with Main Account Transactions)

UK Developers
1

Obligatory: Written with the help of AI

Summary
The current API exposes pot metadata and balance operations, but not the underlying transaction data that drives balance changes. This creates a structural gap for any integration that relies on reconciliation, auditability, or accurate financial modelling.

Problem Statement
At present:

  • /pots → returns pot metadata and balances

  • /transactions → returns transactions for the main account only

There is no way to retrieve transaction-level data for pots, including:

  • Transfers into/out of pots (beyond partial visibility via main account)

  • Spending from pots via virtual cards

  • Internal pot activity affecting balances

This results in:

  • Inability to reconcile pot balances deterministically

  • Missing data for virtual card spending (pot-backed)

  • Broken accounting/budgeting workflows for API consumers

Observed Behaviour (Reproducible)

  1. Create or use an existing pot

  2. Fund it via transfer or spend via a virtual card linked to that pot

  3. Query:

    • /pots → balance reflects change

    • /transactions → does not include corresponding pot-level transaction (especially for virtual card spend)

There is no API path to derive a complete ledger for the pot.

Expected Behaviour
API consumers should be able to retrieve a complete, ordered transaction history per pot, equivalent in fidelity to /transactions for the main account.

Proposed Solution

Option A — Dedicated Endpoint

GET /pots/{pot_id}/transactions

Returns:

  • id

  • created

  • amount

  • description

  • category

  • metadata

  • counterparty (if applicable)

  • source (e.g. transfer, card_payment, interest)

Supports:

  • pagination (before, since, limit)

  • filtering (optional, consistent with /transactions)

Option B — Extend Existing Transactions Endpoint

Allow:

GET /transactions?pot_id={pot_id}

or include:

  • pot_id field in transaction objects where applicable

Key Requirements

  • Read-only access is sufficient (no write operations required)

  • Consistent schema with existing /transactions endpoint

  • Inclusion of virtual card transactions linked to pots

  • Webhook parity (optional but highly valuable)

Use Cases

  • Accurate budgeting and financial planning tools

  • Ledger reconciliation for personal finance systems

  • Automation workflows (e.g. categorisation, reporting)

  • Auditing and historical analysis of pot usage

Why This Matters
Currently, pot balances are non-reconcilable via API, which limits the API’s usefulness for anything beyond basic balance checks. This is a significant constraint given the increasing use of pots and pot-linked virtual cards as primary spending mechanisms.

Providing transaction-level access would:

  • Align pots with the rest of the API surface

  • Eliminate the need for brittle workarounds

  • Unlock higher-quality integrations without increasing write-scope risk

Notes

  • Historical community discussions indicate strong and persistent demand for this capability

  • Some previously observed internal fields (e.g. pot_account_id) suggest the underlying data model already exists

Request
Is this capability on the roadmap, or are there architectural constraints preventing exposure? Even partial support (e.g. read-only, limited history) would significantly improve API usability.

2

The export is the same. Virtual card from a pot doesn’t appear.

It’s been an issue for years, it’s never getting fixed.

3

I am aware this is a known issue with years old requests for it. I was just hoping, given the more technical and formatted request, maybe the team would get behind it. It seems whatever the issue is with why they can’t add it to the API, is the same reason the premium export feature to sheets is also missing pot transactions.

4

A lengthy AI post isn’t going to make any difference.

Monzo know, it’s just so far down a list.

1 Like
5

One can hope. I may need to revert my use of virtual cards with pots, as it seems like this feature isn’t coming any time soon.

6

I use Flex instead now. Put my subscriptions etc on it, default to pay in full, then salary sort the money in to a pot that will pay it. Pay full amount from pot. Done!

7

This seems like a reasonable workaround. I may consider it until the team gets around to implementing the gaps in the API.

8

How does that look on the API? I know for example if I have direct debits charge to a pot, Monzo move the money to the current account from the pot and then make the payment, visible in the main account transactions.

Although, does the API expose the actual transactions charging to Flex, or is it more that you see the flex payment go out after 1 month of it sitting in your flex balance?

9

I have no idea what the API sees that’s different to the sheet, but basically..

Pot +100

Pot-100

Flex payment -100

You can’t see what you owe to Flex as it’s not stored in that way, only the transactions.

10

Okay, I’ve switched over to Flex for all my card-based subscriptions. Although, I’d like to provide some context, as you stated the API does not expose balance for Flex itself, but based on my tests via the playground and my own app - you simply look at all your accounts via /accounts, then find the one with is_flex: true, grab the id, which is the account id, which you pass to the /balance?account_id= endpoint, with the flex account id.

You can then do the same to get the transactions via /transactions?expand[]=merchant&account_id=. It means that you can treat the flex account like a pot with a card you can see the transactions of. You still can’t see the flex terms, like if certain payments are flexed for 1 month vs 3 months, etc but you can see the actual transactions that hit that account.

11

Once you know the pot_account_id, which can be retrieved from metadata on transactions involving the pot(s) in question, you can pass that account ID directly to the /transactions endpoint, using the same account_id query parameter. This is undocumented, so is likely to change (and it has in the past). But, it works for now.

This means you do have to retain some sort of mapping between pots and their account IDs, but it’s doable.

12

I was aware of this undocumented change, but based on my own research, including today and other threads, this has since been patched and is no-longer accessible.

To see, I made a GET request to /transactions?account_id=pot_REDACTEDand receive the below in turn, this has been the case for a while now;

{
  "code": "forbidden.insufficient_permissions",
  "message": "Access forbidden due to insufficient permissions",
  "params": {
    "client_id": "oauthclient_REDACTED",
    "user_id": "REDACTED"
  },
  "retryable": {},
  "marshal_count": 3
}

If you know another endpoint I’m not aware of, I would love to hear it.