¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 ¿ªÔÆÌåÓý
  1. Twsapi
  2. Topics

Is there generic method to format contract for reqContractDetails

 

To get stock contract, it requires only 4 fields.?
?
Name = "SPY"
Exchange = "SMART"
SecType = "STK"
Currency = "USD"
?
For stock options, the 4 fields above + 3 more?
?
Right = "C"
Strike = 650
LastTradeDateOrContractMonth = "20241231"
?
When it comes to futures and futures options, it gets messy. For example, after reading couple of posts in this group, this is the contract definition that I used to subscribe to live data feed for ES futures. Of course, "SecType" = "FUT" and "Exchange" = "SMART" would be more appropriate but here we go.??
?
Name = "ES"
Exchange = "CME"
SecType = "IND"
Currency = "USD"
?
I have no idea why it has to be "IND" instead of "FUT" but somehow it worked for "reqMktData". Meanwhile, when I try to pass this to "reqContractDetails", I get "No security definition was found for the request".?The same happens when I try to request contract details for futures options.
The funny part is that I don't populate these parameters manually, I just request all open orders and positions, copy contract object from there and use it in reContractDetails but IB API returns "No security found" error for it. In other words, IB API returns INCORRECT data that can't be used to make other requests.?
?
Hence the question, Is there a map or table that clearly defines which security type and exchange need to be used with specific securities, e.g. if I have these assets, how do I create method that correctly populates properties for them, so I could use their contract definitions in other API calls, like reqMktData?
?
  • SPY
  • SPY call option
  • ES futures
  • ES futures call option?
  • EURUSD
 

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.

?

?
On Sun, Dec 1, 2024 at 05:01 PM, Andy Sanders wrote:

To get stock contract, it requires only 4 fields.?
?
Name = "SPY"
Exchange = "SMART"
SecType = "STK"
Currency = "USD"
?
For stock options, the 4 fields above + 3 more?
?
Right = "C"
Strike = 650
LastTradeDateOrContractMonth = "20241231"
?
When it comes to futures and futures options, it gets messy. For example, after reading couple of posts in this group, this is the contract definition that I used to subscribe to live data feed for ES futures. Of course, "SecType" = "FUT" and "Exchange" = "SMART" would be more appropriate but here we go.??
?
Name = "ES"
Exchange = "CME"
SecType = "IND"
Currency = "USD"
?
I have no idea why it has to be "IND" instead of "FUT" but somehow it worked for "reqMktData". Meanwhile, when I try to pass this to "reqContractDetails", I get "No security definition was found for the request".?The same happens when I try to request contract details for futures options.
The funny part is that I don't populate these parameters manually, I just request all open orders and positions, copy contract object from there and use it in reContractDetails but IB API returns "No security found" error for it. In other words, IB API returns INCORRECT data that can't be used to make other requests.?
?
Hence the question, Is there a map or table that clearly defines which security type and exchange need to be used with specific securities, e.g. if I have these assets, how do I create method that correctly populates properties for them, so I could use their contract definitions in other API calls, like reqMktData?
?
  • SPY
  • SPY call option
  • ES futures
  • ES futures call option?
  • EURUSD
 

Thank you for the explanation.?
After mentioning that contract can be "overspecified", I tried? to simplify definition instead of complicating it.?
Appeared to be that specifying only 3 fields is enough to specify the contract.?
?
  • ConId
  • SecType
  • LocalSymbol
This information is returned for all open orders and positions. Technically, ConId is not required, but without ConId, reqContractDetails can't find some contracts within 5 seconds, specifically those with options expiring daily, which is not acceptable. Final version cut down to 3 fields only, works fine for stocks, options, forex, futures, futures options.?
?
public static Contract GetContract(InstrumentModel instrument)
{
? var basis = instrument.Basis;
? var derivative = instrument.Derivative;
? var contract = new Contract
? {
? ? //Symbol = basis?.Name,
? ? LocalSymbol = instrument.Name,
? ? //Multiplier = $"{instrument.Leverage}",
? ? //Exchange = instrument.Exchange ?? "SMART",
? ? SecType = GetInstrumentType(instrument.Type),
? ? ConId = int.TryParse(instrument.Id, out var id) ? id : 0,
? ? //Currency = instrument.Currency?.Name ?? nameof(CurrencyEnum.USD)
? };
? //if (derivative is not null)
? //{
? // ?contract.Strike = derivative.Strike ?? 0;
? // ?contract.LastTradeDateOrContractMonth = $"{derivative.Expiration:yyyyMMdd}";
? // ?switch (derivative.Side)
? // ?{
? // ? ?case OptionSideEnum.Put: contract.Right = "P"; break;
? // ? ?case OptionSideEnum.Call: contract.Right = "C"; break;
? // ?}
? //}
? return contract;
}
 

The ConId by itself uniquely identifies the Contract. If you already have a ConId (as you said from orders, positions, or similar objects), SecType and LocalSymbol are not required to retrieve the corresponding ContractDetails object.

´³¨¹°ù²µ±ð²Ô

?

?

On Mon, Dec 2, 2024 at 12:38 AM, Andy Sanders wrote:

Thank you for the explanation.?
After mentioning that contract can be "overspecified", I tried? to simplify definition instead of complicating it.?
Appeared to be that specifying only 3 fields is enough to specify the contract.?
?
  • ConId
  • SecType
  • LocalSymbol
This information is returned for all open orders and positions. Technically, ConId is not required, but without ConId, reqContractDetails can't find some contracts within 5 seconds, specifically those with options expiring daily, which is not acceptable. Final version cut down to 3 fields only, works fine for stocks, options, forex, futures, futures options.?
 

I wish that was true but it is not.?
Just double checked, having only ConID doesn't work for SPY stock, other security types work fine.?
Error validating request.-'bI' : cause - The symbol or the local-symbol or the security id must be entered
 

Actually, I was wrong, yes, ConId is enough.?
It didn't work for SPY because that was the only security I defined manually, so it didn't have ConId.
 

Glad that this works for you.

There is one caveat about requesting contracts by ConId. It may not apply to your use case but you should be aware (and you may already be).

The ConId uniquely identifies a specific instrument, possibly even for a long time. But if the issuer makes any change to the instrument that requires a change to the secId (ISIN/CUSIP, ...) IBKR changes the ConId as well. Even if the Symbol or LocalSymbol of the instrument does not change. Examples are stock splits, change of primary listing exchange, and corporate mergers, but there may be others. SH just went through this in early November.

Generally in these cases, the old ConIds become invalid and result in request errors the moment the instrument change takes place. The Contract option "includeExpired" only works for certain instruments (such as Futures) and does not work for Stocks/ETFs/ETNs etc.

For many use cases, your "four field" contract lookup such as "SH:STK:SMART:USD" might still be the best bet.

´³¨¹°ù²µ±ð²Ô

?
On Mon, Dec 2, 2024 at 07:51 AM, Andy Sanders wrote:

Actually, I was wrong, yes, ConId is enough.?
It didn't work for SPY because that was the only security I defined manually, so it didn't have ConId.

1 - 7 of 7