LaurentM 

That was a simpler version but based on CQG Trader. I meant spreads and flies on futures not options. Anyway, will enquire with Gain about this. Im not keen to try CQG again.

Gain Future's OECAPI (or OneLink API now) demo definitely uses a CQG *datafeed* but I'm confused by the above posts. Isn't CQG just a software and datafeed company? Perhaps LaurentM means that CQG's software platforms haven't performed well in the past...but, if the problem could not be fixed with in the software, then I think the problem is with the broker / clearing house.

As to GAIN's API, it is very flexible and powerful, imo. It provides historical tick backfill and trade execution. There are also a lot of objects/classes (i.e., functionality) already built into the API.

I'm not a big fan of OOP anymore, but you could honestly build any serious retail trading platform on this API...anything that is out there, you could build on this API without having to reinvent the wheel or start too close to the ground and work your way up (that is a subjective statement, I know).

Now, what I wouldn't use this API for is executing an automated (or quasi automated) trading systems. I think there are better solutions/methods to accomplish such a task. I'd use this API to build a platform to trade from...which can mean anything at all but basically means some platform that depends on some level of human interaction (whether it be small or large). The scary problem is..I think...that you're tied to the CQG datafeed when using GAIN's API. I could be very very wrong about that, tho.

Btw, the reason I would use this API to run any quasi-automated system is that it's just too much, it's overkill for that sort of thing. There's too much infrastructure for my tastes. Now, that's not to say it couldn't be done, especially if your a C# or .NET super thug and can produce tons of code in short time...but even if you are, I'd still recommend some kind of python-based solution for developing and deploying systems.

Actually, what I'd really like to see with this API..........open source order flow (or tape reading) trading platform. Wonder if the terms preclude that.

I use the OEC API - have done for a long time. Same for CQG API.

In terms of OEC over CQG/Contimuum API - OEC is really well documented and Continuum isn't documented at all other than the webapi proto files.

Both companies are accessible though and it's rare that a response isn't back within 24 hours from either of them.

From a developer perspective though - OEC wins because of the documentation and the developer forum.

I can answer questions within reason.

fivewhy 

Gain Future's OECAPI (or OneLink API now) demo definitely uses a CQG *datafeed* but I'm confused by the above posts. Isn't CQG just a software and datafeed company? Perhaps LaurentM means that CQG's software platforms haven't performed well in the past...but, if the problem could not be fixed with in the software, then I think the problem is with the broker / clearing house. As to GAIN's API, it is very flexible and powerful, imo. It provides historical tick backfill and trade execution. There are also a lot of objects/classes (i.e., functionality) already built into the API. I'm not a big fan of OOP anymore, but you could honestly build any serious retail trading platform on this API...anything that is out there, you could build on this API without having to reinvent the wheel or start too close to the ground and work your way up (that is a subjective statement, I know). Now, what I wouldn't use this API for is executing an automated (or quasi automated) trading systems. I think there are better solutions/methods to accomplish such a task. I'd use this API to build a platform to trade from...which can mean anything at all but basically means some platform that depends on some level of human interaction (whether it be small or large). The scary problem is..I think...that you're tied to the CQG datafeed when using GAIN's API. I could be very very wrong about that, tho. Btw, the reason I would use this API to run any quasi-automated system is that it's just too much, it's overkill for that sort of thing. There's too much infrastructure for my tastes. Now, that's not to say it couldn't be done, especially if your a C# or .NET super thug and can produce tons of code in short time...but even if you are, I'd still recommend some kind of python-based solution for developing and deploying systems.

Thanks for the detailed answer! Do you know any any chance what is the OEC margining system? Do they use CQG's or only use CQG datafeed and that's all.

What other API would you recommend for quasi-automated system? I'm mainly interested in order routing and do not need a fast solution, just submit an order in a reasonable time.

LaurentM 

Thanks for the detailed answer! Do you know any any chance what is the OEC margining system? Do they use CQG's or only use CQG datafeed and that's all. What other API would you recommend for quasi-automated system? I'm mainly interested in order routing and do not need a fast solution, just submit an order in a reasonable time.

I really do not have all the info to give you a good answer to this, perhaps PD has more info @DionysusToast ?

So, the OECAPI is *not* CQG's API (as Peter said) but the OECAPI from GAIN uses CQG for its data feed because GAIN uses CQG as its data feed. See https://www.nuget.org/packages/OECAPI/

I am also not sure what you mean by OEC's margining system. My understanding is that the available margin is controlled by the the broker's server (i.e., GAIN's server) and info is reported to the user by way of the API. The OEC API documentation is available here: https://gainfutures.com/api/index.html ...there is a class (well I mean namespace) called OEC.API.MarginCalculator which contains classes that might give you the answer you're looking for. Basically, you'd send a request object (which contains an order object) and get a response from the broker server with an object containing the PreTradeCashRequirements for that order. If there is a problem in calculating margin requirements, the problem would probably not be with the API itself, but would instead be with GAIN's broker-server...and that would be a pretty major problem to say the least. And CQG of course has nothing to do with that, it is only the tick data provider (with historic tick back-fill, which is a big deal to me).

Really, you'll have to look at the example source code to get a better understanding...I think that's most important. Oh and the sample source code for OEC API is surprisingly extensive. There's a lot there.

For info on order routing, you're going to need to search the docs and sample code, and prob get in touch with the OECAPI support folks at GAIN. I don't have good answers for that.

As to quasi-automated platforms, that really depends on a lot of different things. My basic answer is look for a data provider who has an API for the language you want to use as well as a broker with an API in the language you want to use. There are some open source python packages for executing on IB's execution API, but IB does not give tick, you need a true data provider for unfiltered tick data. Also, the IB API has to connect through a gateway app that requires a desktop environment, which I find to be stupid. https://www.interactivebrokers.com/en/index.php?f=5041

Honestly, there's no reason you can't use the OECAPI if you're cool with using GAIN as your broker. A pro is that data and order execution are all in one API, but your stuck with that broker and data data feed and it depends on your language tastes. I'm going to go out on a limb and say I'm a fan of CQG's data, and the OEC API is pretty solid if you like .NET. But my ideal solution for a quasi automated system would be something that can run on on a linux box without a desktop environment...preferably even still have order execution and data feed all in the same API. But even if order and data are different APIs, it'd be fine as long as one machine can run both APIs in the same application. There's some problems with that tho, and there are reasons a desktop environment is used. ...but if someone knows a broker with an execution API that will run on a linux box without a desktop environment and is available (cost wise) to retail traders...please lemme know.

Anyway, most decent data providers have decent APIs because that is what people need, it's just that there is not really perfect solutions out there. And I'm anything but an expert, so take this with a grain of salt. ...also, my bad on the rambling. If I had more time, it'd be shorter.

Thanks for the detailed answer!

I need to have a look at the MarginCalculator class this should answer my question I think. The problem I had with CQG is that they tend to over-estimate the margin when you have overlapping spreads and butterflies positions... I'm going to spend some time on the documentation .

Re the Linux box, you could use the Gain FIX API. Look at this in Python: https://github.com/th3sys/transfixed

This is an option that I'm also considering.

LaurentM 

Re the Linux box, you could use the Gain FIX API. Look at this in Python: https://github.com/th3sys/transfixed

omg that's awesome, why don't i know this ...I'm not a coder by trade, and I lack perspective sometimes (all the time). thank you very much.

LaurentM 

Would be also interested to hear if anyone has feedback on this? I am considering moving to Gain to use their FIX connectivity or API.

GAIN has their own APi not related to CQG. They are running over the CQG data but their API is free and you can test it.
The CQG API may be the best in the business but cost from $500 and up per month.

Ilanlm 

GAIN has their own APi not related to CQG. They are running over the CQG data but their API is free and you can test it. The CQG API may be the best in the business but cost from $500 and up per month.

I completely agree with what you've said, but the price I was quoted from CQG was up around $1200 per month as the "lowest" available price. Plus I couldn't get free access just to test it out in sandbox. Not exactly retail-friendly, more geared to institutional(ish) use. But GAIN is solid and they'll give free access to test it, which includes free data and sandbox paper trading (or "sim").

For automated day-trading requiring fast order submission from a custom program, is the GAIN OneLink API adequate, or should I be looking at IB API or some other API? Thanks.