It can very simple for the beginning and I think for the foreseeable future following compromises are acceptable:
no time series, only quotes on shares/etfs/FX
depending on demand quotes can be cached/stale for 5/10/20/30 minutes etc.
depending on demand api access can be provided to users holding only over a certain amount of value in their account
api access should be rate limited (not sure 50 per minute?)
2nd phase can include
ability to put limit buy/sell orders (market orders without up to date quotes might be dangerous for users)
ability to cancel existing orders
ability to query current free funds
ability to query portfolio holdings.
Since most of these features already exist in mobile app, I am sure there are api’s already working for all of these and more. It is a question of rate limiting and opening these apps to your users I suppose.
I think it’d be a faily “easy-win” for the team since they already have the api’s. All that needs to be done is authenticate some api’s for users and rate limit them as liberally or conservatively as they wish.
@kali, thanks for your interest! I do get where you’re coming from and it will be really awesome to have a public API.
This, however is not that easy and simple. Having an API and a publicly available API are two quite different stories.
Just publishing some endpoints and their signatures with some flows guidelines won’t do the job.
Our current APIs are scaled for our apps. If we do a public version we would have to also create rate limiting for each specific endpoint by the accounts that are requesting them. We have quite a few endpoints and limiting them properly is really labour intensive and adding an additional footprint to our current load.
There is also the matter of change management. When we launch a public API we would do so with a proper documentation and endpoint deprecation schema. This requires work. Consider our current method of changing/adding or removing endpoints: we just do it internally and that’s that. The proper way for a public API dictates that this must happen with prior notifications to the APIs users, time for them to react and chasing people that forget to do so.
This is related to peoples’ money so we can’t just break something and let the users’ figure it out on their own.
That being said. We will have a PROPER API. But we do have some kick-ass features that we would like to launch before we do that. All we ask for is patience…
Thanks @noop would be great even if had a basic export function in the interim I think this will help a lot people, even the none technical ones. And may take some heat off for the APIs appreciate the hard work keep up the good work T212 team
I can imagine that the team still is working tirelessly on everything related to pies but after all recently added features is there any chance that we could receive a timeline or approximation for when an API could become available?
Agreed, an official API so we can integrate it with other applications would be amazing.
Having a third party API is so insecure (who dares to ask a user for his login and password for this stuff)
Does any other broker have an API service out there?
For me it would be key that any potential API access meets the following requirements:
Does not impact service on current UI.
Has a test environment key. That way while people test out their coding, it doesn’t impact the live environment.
An API service out there that springs to mind for me, is the Betfair API. It is free for development, but the access key is £299. I don’t think there are any more charges, but then Betfair take a cut of every single bet, so that is probably where the revenue is driven to provide the API service long term.
There are ways that the API can be designed to minimise calls, and limit poor user implementations but poor coding from the user end cannot be fully removed.
