Mac App | Using API


#1

Ok I have had a look around but have not found anything (please add a link to a discussion if this has already been asked)

But as a developer it has just occured to me that using the API I could create a Mac Desktop app for managing my account.

Not having looked at the API docs yet, are all of the features / endpoints available to fully manage an account (payees, moving money etc etc)?

Although I love the mobile only aspect of Starling, I do spend most of my time on a desktop or laptop as opposed to my phone, this is also where I sort out all of my finances, so a desktop app would be awesome.

Before I jump head first into building a Mac App…

  1. is there already something like this going on
  2. would this project be of interest to anyone else
  3. is it even possible using the API
  4. are there some regulations around doing this (im a developer not a banker)

Thoughts?

edit: I could actually build this using a more modern JS framework and wrap this up in something like electron, so it could be available to Windows and Linux users alike


#2

If you aren’t releasing your app you can register on the developer site and get a personal access token. This only allows connection to your account and save much of the OAuth headache.

Most things are available, but some things aren’t available with personal tokens (possibly sending money to external payees, but I can’t remember). It’s all documented on the site.

I use the API to track all my direct debits/recurring card transactions each month. It tracks what’s been paid and what’s due, along with my next pay day, to tell me what I have available.

It also performs a round up function as well as giving me a live transaction feed which gives me details not shown by default in the app (foreign currency and GBP amount in the transaction list, for example).

You are pretty much limited by your imagination and a couple of things unavailable in personal access tokens. There’s no regulations to stick to, bar the common sense of guarding your token.

You could go down the full access route, but you are then regulated and have to submit your app to Starling for checking and approval.


#3

Is there anyway you could screen shot what that looks like without revealing too much personal info?


#4

Please ignore anything that looks like text doesn’t line up, pending transaction amounts don’t tally up, or the fact that it shows a DD as paid even though it’s not due until Monday - I’ve done a copy/paste of various screens etc to show what it looks like and not been too fussy on quality of presentation :slight_smile:

The “Watch” text allows me to add that transaction to my watch list. This allows me to set a date when it’s due for tracking in the main screen. It tracks recurring card payments, Scheduled Payments and also Direct Debits - hence why “DDs from goals” is insufficient for my needs; I need to track all transaction types to be able to decommission my app.

There are also various other screens. On one of them I show a balance after each transaction, obtained from the API. To be honest the bit I use most is the header at the top as I can see how much I have left until pay day.

It’s a wide view as I’ve done this on my laptop, but it re-scales when viewing on my mobile, which is what I do 99% of the time.


#5

That’s awesome.

Is it easy to simply “copy and paste” for other users? Or does it need someone who actually knows what they are doing!? Lol


#6

Hi @Daesimpso, thanks for the great reply. Initially i was thinking of building something personal such as what you have here but further think is that I could launch something a little more public (not to make any money of course, just for the joy of doing it) I dont have any issues with oAuth my last project was a multi oAuth nightmare, so only having to deal with one oAuth process will be very nice. (btw it was swiftsocial if you fancied checking out what I have done in the past and will show at least some level of my abilities).

Love the idea of more easily showing what is left to pay in the month etc. So many idea flowing right now.

Good work :slight_smile:


#7

Definitely need to know what you are doing. It runs on a web server with various components requiring setup. It also stores its database on a MySQL server, which would also require setup and configuration.

It was written just to learn C# and retire my antiquated Excel spreadsheet, and not for public consumption.


#8

Hi @Daesimpso, my idea is to use Go (golang) as a ‘backend’ system that does all of the collection, authentication, general external funtions etc etc and potentially a js (possibly Vue) frontend not decided on frontend as yet, this may change).

This will negate the need for a webserver and allow it to be used on the desktop directly (spawing the go app in the background offering a secure local api for the front end app in electron), this could then be expanded to a ‘web app’ easily as the secure golang api layer can be used anywhere.


#9

Nice thread guys, let us know how it goes @Kirk


#10

Hi Kirk, I don’t know if you’ve seen this thread, but there would definitely be a market for it. I’ve seen a few people on the forum have set up their own personal services, but I’ve not heard of anything being developed more widely.


#11

Hi @Joe_Merriman and @Logan

I am currently putting together some plans and researching the docs. Once I get something started i will possibly start a new thread showing the progress and offering beta tests to those willing to test it out (with approval from Starling of course)


#12

@kirk great plan and good idea.


#13

Sounds great @Kirk


#14

Hi Guys,

Just a quick update for you all, I have now fully completed several key components:

  • oAuth account authorisation flow completed, tested and working correctly
  • token renewal upon login completed
  • a huge focus has been placed on security with heavy encryption methods used (i will not discuss these so please do not ask)
  • multiple Starling accounts can be added to one account
  • basic data being pulled in and sorted (dd’s will be split up into what has been paid this month and what is left to pay)

Due to wanting to place a huge emphasis on security I have decided to make this a web application. Although the main system is fully compiled and obfuscated, I do not want to take the risk of reverse engineering by realeasing it.

Tech stack being used:

Go (golang) backend processing system with seperate security microservice
Laravel for front end layer (all communication is passed to Go application)

Next steps (next two weeks):

  • implement all api functions, read all, write all (payees, savings, dd managment etc)
  • front end coding (design is already in progress)

#15

Cheers for the update - it’s progressing nicely!


#16

Sounds like its coming along nicely.