API Business Models

Forex Trading (API For Automation)

43views

Trading is a topic that started in Amsterdam and it’s been around since roughly 500 years ago. This possibility to freely trade currencies helped stabilized currency exchange rate and since the era of software development people has been trying to develop a lot of trading software for different approach, for example, the platform Interactive Brokers has a trading software which makes it easier for people to trade from their computers and along with this they have a software API, but this API is not as straightforward as we are used to. Why? Because this is something that is happening in real time, is not data that they store and can give you as soon as you request it, so my main question when I tried to work with it was: “How am I going to send a request and not knowing when or what am I going to get data back”.

“Just send the request and check on the other side Miguel” you may say. But the problem here is, when do you know when to check? What if you check the other end before getting a response? We have to remember that whenever we request things to API the time response is not always the same.

There are many ways to approach this and I want to share with you what I did and what I think it was the best path to follow.

I have worked with Python for a long time now and I consider this one of the strongest languages when working with AI and Automation. I gained a pretty good knowledge as well as combining it with Azure and AWS, doing automation on Web Browsers with Selenium and scraping data from websites. I had the great joy of sharing some of this knowledge with people at conferences and events, where by the way, is one of the best ways to grow your expertise on a topic. You can not imagine the number of things that you can take from questions from an audience of 200-300 people. Basically you have 300 pairs of eyes analyzing from every angle, what you are doing. You have to be prepared for everything.

Not long ago I was working building a dashboard for a trading system for a company. All I needed to do was to get data from an IPA on real time, display the prices and the status of the account. This company asked me to do this with Interactive Brokers (IB) which they have an online trading platform. At the same time they provide an API Software  that you can use to integrate with the application that you are building. So, you end up having 3 parts:

  1. Your Software
  2. The API
  3. TWS

TWS is their software which interacts with the API. Long story short, you have your software that you integrate with their API and this communicates with their platform that you have installed in a server or your local machine to do any kind of actions that you may need without having to go into the software.

The problem here is that this API has two parts (Wrappers) which one of them is used to send the request to TWS, requests like: Get Account Info, Get Currency Pair Info, Etc.. and the other part is where they will send the response. We can think of this like if two people are playing throwing – catching a ball and the first one is you sending the request and on the other end you cannot know exactly when the ball is going to start going down until you keep an eye on it and be ready to catch it. This other part is simulating that TWS gave you the response through the other end.

As you notice this is as complicated as it is to explain, you can find a little bit more about it at https://interactivebrokers.github.io/tws-api/introduction.html 

The work around that we found (picture below) for this, was to structure very well our application. Building our objects and knowing what we wanted and what we were going to use. Then, it was almost obvious that we needed to work with threads, since we needed to wait for data back without interrupting the application.

As we can see in the picture we have our reqData method which populates and calls the other method reqHistoricalData (part of the API). Once you call this method, it will return the value through other methods (which they do other things). But the one that we want to focus on is the historicalDataEnd since this is the one that is going to tell us when we finish receiving data so we can use it.

On the reqData method we can see that after we call the reqHistoricalData we go into a while loop, which is checking for the value of reqId which is a global variable, this is going to change at historicalDataEnd.

This is a little part of how we address this type of situation, we can use flags to know when a value changes while we wait for them on the other end.

Miguel Tannous
Software Engineer with strong knowledge in Object-oriented design, test driven development and UI/UX Front-End development. High interest in games and working with Hardware. Quick learner and early adopter of new technologies; excellent time management and multitasking skills with a very analytical mindset that translates into exceptional problem solving and troubleshooting abilities. Finally, a collaborative person in the work environment, successful working on a team or individual setting, as well as a very adaptive individual in constantly changing environments.

APIdays | Events | News | Intelligence

Attend APIdays conferences

The Worlds leading API Conferences
with 9 Conferences in 2019:

Singapore, Zurich, Helsinki, Amsterdam, San Francisco, Sydney, Barcelona, London, Paris.

Get the API Landscape

The essential 450 companies

Get the API Landscape
Industry Reports

Download our free reports

The State Of Api Documentation: 2017 Edition
  • State of API Documentation
  • The State of Banking APIs
  • GraphQL: all your queries answered
  • APIE Serverless Architecture