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:
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)
-
Create or use an existing pot
-
Fund it via transfer or spend via a virtual card linked to that pot
-
Query:
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.
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.
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.
A lengthy AI post isn’t going to make any difference.
Monzo know, it’s just so far down a list.
1 Like
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.
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!
This seems like a reasonable workaround. I may consider it until the team gets around to implementing the gaps in the API.
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?
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.
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.
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.
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.
@BradleyKing It appears as though you’re passing the pot ID, not the pot account ID. There’s a difference. If you list the transactions for your account, and find a transaction which transfers either in or out of the pot you’re interested in, you should be able to find the pot account ID in the metadata of the transaction, under metadata.pot_account_id. The pot account ID starts with acc_.
This hasn’t been patched for me, and still works just fine.
@Deitrix Thank you for coming back and confirming the exact values used. Sadly, it seems like while you can indeed get pot transfer transactions this way, showing transfers between this pot and other pots and this pot and your personal account, it does not allow you to see any transactions related to virtual card spending on a pot.
Due to this, unless I’m mistaken, I will continue to use Flex until Monzo considers adding virtual card pot spending to this endpoint, or to a future endpoint.
I still see how this could be useful if I wanted to bring pot-to-pot transfers to my finance dashboard, as currently I only capture transfers between pots and the personal account, which is 99% of my transfers between pots anywhere, but it would still be a nice addition.
This thread remains an active issue.