API /pots by account?

Developers
1

With the ability to now have multiple accounts (Joint, Business beta).

Is there a way to access /pots by account? I have 2 accounts, but only see one set of pots (Personal)

1 Like
2

This does make sense, and I guess you could have a hybrid between the old and new accounts screens - swipe sideways to switch accounts, scroll to see the Pots on that account.

3

Sorry, I was specially talking about the API.

I’ve updated my q

4

There isn’t currently. You can access the pots by id if you know what they are.

I scan through the last couple of months of joint account transactions the find active pots and then poll them individually to get the details. Not very API efficient but it’s the only way :neutral_face:

5

I’ll try that.

I’m trying to write a webhooks l for my business account to move VAT.

I’ll try that! Thanks

6

Sorry that’s my bad, half asleep so didn’t notice it was in the developers category! Still think my idea could work in the UI though :wink:

1 Like
7

Try passing a current_account_id field to /pots. I don’t think we’ve documented this yet! :slight_smile:

4 Likes
8

I’ll try that!

perfect that!

9

Hi Tim, I’ve been using the /pots endpoint for some time now, but since today it returns 400, stating that the current_account_id field is required. I have tried passing that field to /pots but I get the same error.

Passing fields to other endpoints works fine so it shouldn’t be an issue in forming the request. Any idea what could be wrong?

10

Hi Alessandro,

Thanks for letting us know about this, and sorry this change broke your integration.

We updated the API this morning, current_account_id is now a required parameter. You need to pass it as a query string parameter. I’ll get the updated docs published ASAP, but for now here’s the new example httpie request:

http "https://api.monzo.com/pots" \
    "current_account_id==$account_id" \
    "Authorization: Bearer $access_token"
11

Thanks Joseph! I just realised that I was sending my parameters as POST data instead of query strings.

Curiously, I’ve been doing this with /transactions as well, which instead seems to accept parameters as POST data. Not sure if that’s intended behaviour :slight_smile:

12

Thanks for pointing that out, it looks like the /transactions endpoint is a bit more flexible about the request format. Query string parameters should generally be a safe bet for GET requests :+1:

2 Likes
13

@jtxyz I ended up here because my own API client broke on this API change. I know that backwards-incompatible changes are expected.

Is there like a feed we devs can follow to be alerted to such things? Like a changelog for the API or an announcements channel?

I didn’t see it at the top of https://docs.monzo.com

(It took me quite a lot of digging to work out this was an API change and find my way here)

14

It’s intended behaviour, for weird legacy reasons. (We use /transactions internally as part of the /feed API, and sometimes we need to pass it more data than would fit in a query string, so we put it in the body instead, as “POST” data. Curiously, although the HTTP spec doesn’t allow bodies for GET requests, the HTTP server in Go’s standard library allows it…)

1 Like
15

I can definitely echo this. I’ve discovered this change by seeing my project break, which is definitely negative in terms of user experience, and had to dig up this PR to realise there had been a breaking change to the API.

I have sent a ping to the folks on the Monzo Twitter account, who have relayed this to the tech team, who apparently said that the best place to go to for this is this forum.

So either there’s been a misunderstanding, or there’s no place where API updates are announced. Which sounds scary to be both as a developer, because it means the API is unstable and can break at any point, and as a customer, because it means Monzo is willingly putting out something that can break under its users at any time.

I’d hate for the API to go away, because I think that’s part of what makes Monzo so much more than just a bank, and increases hugely the possibility to make it your own by adapting it to your needs or to what you’re comfortable with.

What I’d suggest is two things:

  1. Publish a web page displaying an up-to-date changelog of the API. An entry on this could be as simple as “Add an optional property X to endpoint Y”. towncrier is a fantastic tool to automate this and make this bit as lightweight as possible. On top of that, it should include an RSS feed people can subscribe to. Tools like hugo would allow publishing that web page quite easily, and the RSS at no additional cost.
  2. Give heads up about uncoming breaking change to the API ahead of rolling out onto production. This would ideally be done via an announcement channel (e.g. a mailing list or a Matrix chat room), but could also just be an entry on the page/feed suggested in step 1 (e.g. prefixed with “[upcoming breaking change]” to attract the attention of those watching).

I know Monzo doesn’t have a lot of resources to allocate to the API, and I can guess it got worse with the COVID-19 crisis. This is why I’ve tried to think up something that would be quite costly and of low overhead for the team (I haven’t spent more than a few minutes on this though, so it can probably be improved to be even more efficient).

However, just implementing something like that would be night and day to the developers using the API to develop third-party projects, like me and the two other folks here, and would help immensely.

1 Like
16

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.