开云体育

The Contract object contains a lot of information about an instrument, but the various API request calls thatt take Contract object parameters transmit only a subset of those to TWS/IBGW. Which those are is not defined by the API specification, so the best practice is to always use complete Contract objects that you receive from IBKR through reqContractDetails calls. I understand that many code samples give you a different impression (e.g. they make contract objects up on the fly) but "home made" Contract objects do not result in reliable results over long periods of time.

Think about reqContractDetails as a database query. Depending on what you want to see, you provide more or less attributes to the query:

• If you try to get the contracts for all ES futures that IBKR currently knows about, for example, you'd specify in the contract you provide to reqContractDetails as little as ES:FUT:CME and you might set the includeExpired flag to true. Similar you could ask, as another example, for a list with one Contract for each exchange a stock is listed on.
• But on the other side, if you are just interested in ESZ4, you'd set localName to ESZ4 or the specify the future's expiration through lastTradeDateOrContractMonth (just like you did for the stock option)
• And if you simply want to get the Contract for what IBKR currently considers the ES front month future, simply make a reqContractDetails for ES:CONTFUT:CME.

But you would generally not call reqContractDetails with a complete Contract object you have received from IBKR. Chances are that those contracts over-specify the instrument which can indeed result in a "No security definition was found" error.

One convenient way to design your reqContractDetails queries (you'd do that once) is ?Richard King's Another path are the complete TWS API client applications that ship with TWS API (such as the pre-compiled Java and C# apps). They also have screens where you quickly can experiment with reqContractDetails. But Richard's tool is more purpose built and might get you results quicker.

Many of our members call reqContractDetails for the instruments they are interested in when their client applications start, or at least once per session, and use the resulting Contract object for all requests. The returned ContractDetails object(s) do not just contain the Contract you are looking for, but also the actual trading hours for the next few days. This is very helpful to detect short notice changes (emergencies, local events) and the exact trading hours around public holidays.

You can also search our message archive, since there are several topics about how to specify contract queries for various instrument types.

Hope this helps as a direction for a reliable approach.

闯ü谤驳别苍

PS. When you request market data with a contract that specifies just ES:IND:CME:USD you get very likely data for the ES Index and not the ES Future. If you want to request data for the ES Future with a "home made" contract, specify the fields I mentioned above: type such as type FUT plus localName or lastTradeDateOrContractMonth or type CONTFUT.

?