Brokerage Web APIs: Capabilities, Risks, and Adoption

# Are there any brokerages which use URL-based web APIs?


# Are there any brokerages which use URL-based web APIs?












We already have a list of brokerages that provide apis. What about brokerages that provide web apis?

For example, Collective2 has a url-based web api for entering trades. Are there any brokerages that provide a similar interface for getting data or entering orders?

## Answer by NPE (score 6, accepted)

https://quant.stackexchange.com/a/1585

I haven't come across brokerages with Web APIs. In fact, there are several reasons why I think such APIs would be a bad idea for live trading:

- Security would be a concern, both for authentication and encryption of sensitive data (perhaps the latter could be addressed by using HTTPS).

- The HTTP protocol is not designed for transactional data of this sort. It is not all that infrequent that, while browsing the Web, one sees timeouts, "bad gateway" errors and other glitches. Now imagine this happening as you submit an order. You don't know whether the order has made it to the broker, whether it's out on the market, has been filled etc. A specialized protocol can handle this much better.

- If you lose your connectivity to the broker, it's hard for them to know that and take corrective action on your behalf (e.g. pull all your orders from the market).

- It is not at all clear what the mechanism for feeding data (e.g. fills) back to you might be.

I think it might be possible to make this work (in a square-peg-in-a-round-hole kind of way), but there are clearly better alternatives.

## Answer by John Carse (score 6)

https://quant.stackexchange.com/a/1592

TD Ameritrade offers web-apis -- you have to have an account with TD Ameritrade to get access, but the portal page can be found at TD AMERITRADE API Support Portal. It seems pretty robust and there are many that are using it for automated trading -- I'm currently coding to it in Java.

Good luck!

## Answer by Steve Severance (score 5)

https://quant.stackexchange.com/a/1588

There is no specific reason that these APIs don't exist. There are no concerns around security or performance that are specific to the HTTP protocol itself. HTTP can be easily secured with HTTPS (much more testing than your brokers custom solution). Traditionally HTTP has had less support for streaming data over persistent connections as the main way to do this was a chunked encoded stream of unlimited length. The introduction of web sockets removes any impediment to using an HTTP + WebSockets based solution.

A custom protocol would still need to implement error handling, checking for dropped packets, connection disruption, etc... You could implement this just fine in HTTP. Developers of custom protocols often describe efficiencies of using custom binary protocols but there are rarely accurate and detailed measurements to back up their assertions. It would be very simple to build a very high performance solution using nginx and WebSockets that supported any piece of functionality that brokers usually provide.

I would suspect that there is not more of this since most financial developers don't typically turn to these types of solutions just because that is not the way things have been done. Inertia in any industry can be very powerful.

In either case various FIX engines are already heavily tested and in use at scale and since most people trading at scale are using FIX there is little incentive to invest in developing a web based technology. If a brokerage already has an existing custom API the ROI of moving to a HTTP based solution is probably almost zero.

## Answer by Ronny Daniel (score 3)

https://quant.stackexchange.com/a/1601

In the footer of this page, you can find a list of brokerages, they provide API(web or stripped down) services and cheap brokerages.

http://www.elitetrader.com/vb/forumdisplay.php?s=eff1f8fd5f8145d41006a327f286ca27&forumid=48

Thnks Roshan