Genesis API and custom software

In the past few months I wrote several ATS and custom execution or front end software for serious Genesis traders.
The C++ API was the only one available then.
It is a very comprehensive API, with little or no documentation and simply required an expert level C++ software designer.
The good thing is : it can do about anything, it's very fast, has a gazilion options and features.
But it is not so accessible.

Now, a new API is becoming available. It is much simpler (no comparison!). And will make it possible to address Genesis API in more languages. If used in C++ it should be very fast as well. With full documentation and easier to code for, it should make many traders happy.

For now, I know well enough the standard, more sophisticated API so I don't think I will use the simpler one. Unless Genesis suggests otherwise I guess.
I will continue building custom ATS or front ends for serious traders (and for myself as well obviously). Actually I am still using and building software for IB and Genesis.
However, as far as nasdaq stocks are concerned, Genesis rules imho.

So more and more traders will be able to build their own software for Genesis. Some will still require custom software architects for more complex and speed optimized solutions.

Funny, I still remember times when IB would fight the idea of retail API access. I lobbied long and hard on this. Some of the threads are still in ET archives.. lol
Soon, if not the case already, a direct access broker without API won't be in business.

These APIs should continue to improve as the battle of the bots is raging in the markets.

I just received the basic API last week and have been going through it, so I guess I can give my opinion of it from a non-expert programmer point of view.

Reading over the documentation it seems like a pretty robust API and I'm excited to start using it. The documentation is basically a list of functions with a basic structural example of how each function is used. However examples are not shown in a context, they're as is. It pretty much serves as a function reference index. It doesn't show you how to write your own bridge app... that, it leaves up to you.

I guess that's where most of us who aren't too familiar with programming will run into some problems. For instance, the farthest I've gotten with it is being able to initialize the API (not very far)... as far as dealing with basic callback functions like creating sessions for login, etc, I'm still struggling with. It would be nice if Genesis could include a sample outline of what the steps would be in building a connection... some sample code of the basic process (eg., from initialization to quote extraction) would be really useful and would go very far in helping code something up.

The biggest hurdle, in my belief, is that the user base is still pretty small (judging from the # of posts to this thread anyway). One of the things that has made the IB API so accessible is just the sheer number of people using it, sharing code, and giving each other support. It would be nice if we could get that kind of collaboration going with the Genesis API. If anyone's interested in learning about the API, or using it, perhaps we could use this thread as a repository of information... with tntneo's blessing of course . If not, just PM me, perhaps we could get some things going that way.

Anyway, I agree with tntneo, the API is definitely going to be a key feature for any broker in the future... hopefully not until I get my bots up and running though

In the past few months I wrote several ATS and custom execution or front end software for serious Genesis traders.
The C++ API was the only one available then.
It is a very comprehensive API, with little or no documentation and simply required an expert level C++ software designer.
The good thing is : it can do about anything, it's very fast, has a gazilion options and features.
But it is not so accessible.

Now, a new API is becoming available. It is much simpler (no comparison!). And will make it possible to address Genesis API in more languages. If used in C++ it should be very fast as well. With full documentation and easier to code for, it should make many traders happy.

For now, I know well enough the standard, more sophisticated API so I don't think I will use the simpler one. Unless Genesis suggests otherwise I guess.
I will continue building custom ATS or front ends for serious traders (and for myself as well obviously). Actually I am still using and building software for IB and Genesis.
However, as far as nasdaq stocks are concerned, Genesis rules imho.

So more and more traders will be able to build their own software for Genesis. Some will still require custom software architects for more complex and speed optimized solutions.

Funny, I still remember times when IB would fight the idea of retail API access. I lobbied long and hard on this. Some of the threads are still in ET archives.. lol
Soon, if not the case already, a direct access broker without API won't be in business.

These APIs should continue to improve as the battle of the bots is raging in the markets.

More...

Hi tntneo,

Very interesting. As you mention the possibily to address Genesis API in more languages, I wonder how much the approach remains dependend upon a single OS?

Is the Genesis API interface always based on Activex or do they also provide for socket interfaces, somewhat similar to Ib's TWS? I think a socket (OS-blind) interface combined with anything C++ gives one an almost total freedom to do things in the way the user thinks is best for him.

Having to bridge to anything COM or Activex can become very messy if you leave the tent of Activex, i.e. the OS guys got you captive.

I agree with you nononsense.
Genesis is not a big corporation with a large staff developping for them. I think their software is built in house (which has many advantages and this disadvantage).

step by step..
personnaly I don't like .net and hate activeX.
straight winapi C++ (well using mfc anyway if i must) is my prefered way.
however, it is easier now to use their API thanks to .net than before, so they get credit for that, no question.

it's funny, because I am still not sure which API I prefer : Genesis or IB.
I think I prefer IB for now.. and they are os independent. for now IB recovers more easily from an internet disruption and other things like that.
You need to do more things yourself with Genesis API. On the other hand you are in fuller control.

Genesis as an ATS broker vs IB is an easy battle, and it is won without question by Genesis. So I hope their API for remote traders continue to improve. Although I'd rather not have too many traders using Genesis like I do !
heh

I also just got their basic API and plan on developing an interface to Laser. I was hoping it would work with VB6, but it appears that I will need to use VB.Net. I'm pretty much a VB expert, but I now need to get spooled up on .Net in order to tackle this project. I did notice some sort of TestNetAPI project, so maybe that contains some type of an example project. Have you looked at this project yet? I can't open it because I don't have .Net loaded on my machine.

If they didn't provide any sample projects, then that's extremely dissappointing. It really makes no sense, they should provide some simple working example projects that demonstrate the API functionality.

Yeah, they do have a project file in there, but I believe it's the source for the .dll's (someone please correct me if I'm wrong). It's written in C, though. You can take a look at the code by just using your text editor and looking at TestAPIB.c. That's how I've been doing it at least. I'm trying to use it as a guide, but I'm not familiar with C, so it's a bit of a challenge. I'm going to talk to Serge about that project file, so I'll let you know how it should be used.

If you have some programming experience, you should probably do ok. Some of the challenge for me, is that I'm trying to interface the .dll with python, so it takes some extra manipulating to get the functions to work right. I might have to go the .Net route in the end, especially if that c file ends up being the example program. If I have to use .Net, I'll sure miss being able to work with python, for instance I can call the dll and initialize the API by just typing:

I agree with you nononsense.
Genesis is not a big corporation with a large staff developping for them. I think their software is built in house (which has many advantages and this disadvantage).

step by step..
personnaly I don't like .net and hate activeX.
straight winapi C++ (well using mfc anyway if i must) is my prefered way.
however, it is easier now to use their API thanks to .net than before, so they get credit for that, no question.

it's funny, because I am still not sure which API I prefer : Genesis or IB.
I think I prefer IB for now.. and they are os independent. for now IB recovers more easily from an internet disruption and other things like that.
You need to do more things yourself with Genesis API. On the other hand you are in fuller control.

Genesis as an ATS broker vs IB is an easy battle, and it is won without question by Genesis. So I hope their API for remote traders continue to improve. Although I'd rather not have too many traders using Genesis like I do !
heh

More...

Trade-Ideas offers its API in multiple languages directly from its website. The videos and plain English instructions make it a simple addition to a brokers API. Judge for yourself..http://www.trade-ideas.com/ForDevelopers/

Ok, I've been working with a friend of mine who has visual studio .net and we went through the project file that is in the GenSrc folder. I originally thought it was the source code for the dll's due to the title of the folder, but after messing around a bit with the compiler we were able to build an executable from the source file. It turns out it was an example program!

Basically, it creates a window with login/logout buttons, and some buy/sell, and bid/ask buttons. It's obviusoly not meant to be standalone, but it serves the basis for future work.

My apologies for any confusion I caused with my earlier mumblings, but I did warn that my opinions wer from a non-expert programmer . Anyway, I'm very happy that the basic API is more self sufficient then I thought. Looks like I'll be needing to learn .Net, though .

Genesis' API was designed originally for true professional trading (I don;t mean prop, i mead pro in the true sense of the word).
That's why for the average joe, who doesn't have a team of developers it wasn't easy.
But this was before.

I've started with their first C++ API. Now, I think they have 4 versions. The have documentation for the most popular simple version.
The rest have a very good TESTAPI application that you can follow pretty well. Connection, Quotes and Orders are in there and you can build on top of it.

That is the first thing my programmers did. And they told me it works well doing it that way.

If you got the API from Genesis, open the SRC folder and find the TESTAPI folder. Look at some .h files - it can give you some direction.

Also, TNT, I disagree with you on one thing with Genesis. Last I've heard, they have over 20 software developers on staff. That is a good mid size software company. definitely larger then many DotComs that were around.

Maybe traders should try to create a post on ET with API questions and have other API users answer them and once in a while have Genesis Chime in?

Anonymous, I realize I didn't explain myself well.
What I meant is Genesis has in house programming staff, their software is proprietary. they also have their own trading bots etc..
they can adapt it and don't need to wait on an external company to adapt to whatever SEC, Nasd or whoever is changing.
That's great !

I only wanted to point out that building super easy api, document it etc, is not their top priority. Their staff are very busy with many other more important things.

And regardless, they managed to create a new simpler API to address demand from retail and prop traders.
the full C++ API works very well, they could have simply asked everyone to use it and contract software companies to code for it. I applaude them for an approach that did great for IB, I wish them the same success with it.