I'd like to collaborate on building another open source broker-neutral order execution suite. Unlike Tradelink: 1. It will use PHP (or Python or Java) and be able to run on a free LAMPP webserver. 2. It will support Etrade, Tradier, collective2, Tradeking (and more). Currently, I have a version running on the Redhat Openshift cloud. The current code can be found here: https://bitbucket.org/PagerProject/shrine The goal is to make it much easier for developers to connect to the various brokers.
Great idea. This will be very handy. I currently use the Tradier API and will be more then happy to test for you once you are ready.
how representative of the whole freebee, gimme gimme, linux crowd. You want it gift wrapped delivered to your doorsteps or would you have it shoved up your arse? Cheapos!!! Do your own work or contribute.
there has been several attempts at this, and everytime they failed because of the lack of interest however, I checked your code in the repository, and the etrade part seemed interesting. Have you tried IB too ?
No. . . . I'm doing a "poor man's" broker-neutral system. IB's minimum deposit is $10K (which many people don't have). That said, in the future, this software will support IB. P.S. Thanks for letting me know there has been a lack of interest. Having worked on the Etrade API SDK for some time, I think that there is a little commercial viability for this project. I can afford to give away this section of code . . . but on the other hand it seems like I could get paid for it (and in turn, pay the other programmers to help me add more brokers to it . . .
it's still an interesting project, but the "dev market" for it is not there yet it's also quite easy to integrate ET PHP API, so building another dev framework for it might be overkilled
I disagree that it is "easy" to integrade the Etrade PHP SDK API. Are you aware that they changed the authorization (regarding SSL v.3) some time before October 20th (and that broke their SDK)? Are you aware that they modified their process regarding the access_token also? They are "planning" to release a new SDK *weeks* from now! I have hired programmers to help integrate the Etrade API and seen their developer forum. Many people struggle with the Etrade API SDK in particular. I was even on the phone with a web development company that was willing to pay me $1500 to integrate this specific API. Last I checked, they still don't have it working (in part because Etrade broke their own system before releasing an update). Moreover, the Etrade API really requires what seems like 10 usernames and passwords just to get authorization. account_id oauth_consumer_key + oauth_consumer_secret temporary oauth_token + oauth_token_secret manual username + password oauth_verifier (related to the token) access_token + access_token_secret . . . and then some of these values expire at different rates of speed ranging from 2 hours to 1 day to 1 week! That along with a cumbersome 3-legged OAuth process that requires human interaction at least once a week. Keep in mind that the Etrade API SDK has redundant calls to get repeated information. I have no idea why they did not streamline the process within their SDK. So, I think there is a great benefit for having an open source wrapper around their SDK . . . so that several programmers can solve the problem with Etrade breaks their own system. Also, the design of my system is supposed to make it easy to switch to other brokers. Tradelink proves the there is some demand for broker-neutral systems. In my mind working with ALL of the APIs at a broker (or even with multiple brokers) should be as easy as: 1. Updating a config file. 2. Passing in an array (JSON). 3. Getting an array (JSON) as a response. So . . . In *theory* Etrade's API is "easy". In reality the design itself had me looking into open source OAuth systems to replace their SDK.
I am aware of the OAuth mess, but that's not what I was referring to as "easy" the problem is that the ET API is still v0, basically it's beta, and yes they over protective, because they are obsessed with security and paranoid about everything else, like amateurs usually are, so they make it very complicated to authenticate and exchange "secure" trading messages. the integration of the API is not that difficult though, if that company you refer to can't do it. maybe they should consider hiring better people or change their line of business of course, in these days and age, nobody has any idea about anything when it comes to API integration and writing good non-OO code.