Is anyone automating anything (preferably Options) with the IB platform? I'm interested in your experience and what the possibilities are.
IB is what you expect a Java API from the 90s to look like. ib_insync is great, I use the async capacity and look like a genius.
The only limitations are your imagination, latency and query rate. Some things are more difficult to achieve than others but it works relatively well. The risk with 3rd party stuff like ib_insync is that if you build using it and it will be abandoned, you will need to rewrite your code from the start.
That's why I always privately fork important stuff like ib_insync. Helps me get familiar with the codebase and I feel completely comfortable modifying it. If/when IB writes yet another API and deprecates the current one, then the places where I use IB directly are very limited as it is so there would only be a few places to change: - Historical data: my own source pulled from IB - Real-time data: relaying IB's real-time data from my source to multiple clients - Order management (currently using IB directly) So the rest of my system can continue to work without IB. This isn't on purpose, just that good, iterative design (lol - pat on back) ends up having these kinds of characteristics organically.
FWIW ... I took a road less traveled. Don't necessarily recommend it ... but it's worked well for me ... and I trade options ... lots of option spreads I turned the IB TWS Sample code into an app server for my existing systems. I traced the interaction between the Sample's UI and API's, and inserted code in the Sample code that 1) distinguishes between requests from the UI vs my systems; 2) receives input from and sends output to my systems; 3) adds validation steps for certain functions to be more robust since the Sample code was intended to be an example, not robust production code. Once I figured out coding around asynchronous messaging, the rest was 'reasonably' straightforward since I could more-or-less duplicate what I was trying to do with the UI functions. I took that approach because 1) thought I could stand up an app server faster by leveraging code that's already up and functioning; 2) it would insulate me from some of the intricacies of IB API version upgrades; 3) working in parallel with the UI would provide a "built-in" debugging capability; 4) any issue I had (or thought I had) would be addressed thru IB support as long as I could duplicate the issue within the UI ... and if I couldn't duplicate it with the UI, then I learned something! So ...... I had "something" up and running in reasonable time. The API version upgrade in May went quickly. I've made good use of the UI processing in parallel with my own code for troubleshooting. And, the one issue I thought I had, was addressed by IB support, and I believe it helped that I presented it in the context of an issue with the Sample code. There are lots of reasons not to approach it that way ... but so far I have no regrets.
Thanks for all the feedback. I actually don't want to do too much. I'm a Mac user and I've created a Trading Journal in Filemaker. It's a bit of a hassle manually entering my trades so I thought I'd look to automate this. I have to weigh up the programming effort versus a COTS solution. I've installed a trial TradingDiary Pro but due to the lack of decent documentation, it may take me as long to learn as it will to upgrade my Journal to import the feeds from IB. Basically, I'd like to look at the status of my Open positions - check the moneyness; check the DTE; check the Unrealised P/L and decide on my trades for the following day/s. Then it would be good to review an underlying over a period of time - say MSFT - "What has my history been with this stock?" Any advice?
hi do you have any resources or know where I can learn how to use the IB_insync package to do automated trading
That seems like a dangerous question to answer. The documentation says how you can use the API to call IB functionality but does not teach you about automated trading _at all_.