Developer API flavour

On the roadmap is developer API. Is there any early thoughts on what this might include ?

Maybe openapi (https://www.openapis.org/) based ?

This could get us a way to add unsupported accounts - ie on my desktop I can periodically get the account balances then push them to emma. I do this already for https://evolvemyretirement.com/.

It’s quite far ahead on our roadmap, but would be good to know if this is the main reason you’d be interested in the developer API?

What other things would you love to do with an API?

Well, first thoughts -

  • Push todays account values ( for accounts not supported )
  • Pull historical values to compare via effective interest rates
  • Pull into google sheets for further manipulations / analytics
  • Push to retirement planning services
  • Import / export in json / csv formats

Some great ideas here - thanks for sharing.

You can already export to csv and then add this to excel/ Google sheets etc. Here’s how - Export my data | Emma App

We have csv import on our long-term roadmap too. What kind of info could you see yourself importing?

Not via an API though, so can’t be automated.

One thing that would be very helpful is to prioritise / bring forward is some way to automate updating a “manual” balance.

This could even be reading a file from google drive once a day or something.

I’m going to keep pushing on this :slight_smile:

I suggest a new account type, say “csv from google drive”, similar to existing real accounts but -

  • Configured with csv location ( google drive is first thought but could be others such as iCloud, dropbox etc )
  • Is refreshed at the same time as other real accounts
  • File contains list of -
    • date
    • balance
    • transactions
    • maybe other info that real accounts use

This gives us a chance to download unsupported accounts statements manually and create the file. I expect we can build up a library of statement converters.

Nice thing is that this doesn’t impact security of account login details.

Other formats ( eg json ) is also fine if that better matches the internal structures.

I guess you might also want to consider a way for us to write our own downloaders as a emma plugin.

What would make this different to smart rules?

Smart rules is about linking manual transactions - so still manual data entry.

The proposal here is to automate data entry for unsupported banks - replace typing with regular reading of a file ( which is created/updated outside of emma ).