Normally, the conId cannot change. In your case, the stock references to another ISIN and therefore to another conId. The only thing you can do is to update your conId if the symbol does not match with the previous conId.

My approach to this problem is to send the order with the conid that you think is right. If the conid is no longer valid, you will receive an error message. Catch this error message by making a contract details query to IB (using symbol, exchange) and then use the result as the new conid. You can do this automatically in the code and it is fairly fast.

Good luck.

I generally prefer to make as few assumptions about the persistence, validity and relevance of conids as possible. Due to scarcity of information I prefer to treat them as merely a "black box" interface sporadically exposed in the API for some peculiar tasks when there is no alternatives based on more universal tools, and not quite reliably useful beyond that.?

So yes, I'd suggest if/when you need conids just get them from contract data received in portfolio updates and by fetching stock lookup. I usually assume that a received Conid would likely be useful for a single trading day at most.

Updating conids is really cheap and easy anyway.

I also have had cases where conid's changed. In my case it related to ETFs which moved from one exchange to another (e.g. NYSE to NASDAQ or vice versa). My experience is that IB then considered the previous listing as the "old listing" (hence the ".OLD" appended to the name) and starts pointing to a new conid. This persists for a few days after which all references to the old listing are removed.
I solved this by running a program once per day which checks the conid's for all symbols that I'm following and compare the returned conid with the conid which I have registered. If there is a difference I receive a warning and do a manual check to see whether I need to update the stored conid.

开云体育