Jump to content
  • 0

Order API Behaviour - How to formally raise a bug with IG?'


Tipper258

Question

Issue 1. The API does not behave as documented

The streaming API does not behave like the documentation, it never raises a WOU, always an OPU and it can have 2 different bodies. You have to inspect the body for presence of certain properties to determine what type of message it is. No biggie, can work round this once figured out this is what happens in both demo and live spread bet accounts.

Issue 2. forceOpen behaviour

Having used IG for many years, I'm very familiar with the web platform behaviour of forceOpen. Set it to true and your working order doesn't impact existing orders when the order executes. Set it to false and the order will apply to any open position in the same epic, quite how it decides which position to impact if you have multiple open is unknown.

In the REST API, the documentation says the default for forceOpen is true for working orders. Certainly if I try to set it to true I get a 400 with invalid.forceOpen error. If I don't set it, when the order is executed it behaves as if it were set to false and closes open positions which is rather unhelpful for the strategy.

When using the API companion, and I paste in the exact request body, with forceOpen set to true, it doesn't complain, off it goes and creates a working order. Mind you it returns the dealRef I specified but doesn't create the order with the dealRef which I guess is an implementation 'thing' with the companion, but then again that says maybe it actually strip out the forceOpen true before making the real API call too? Hard to know, or have confidence it's a true reflection of the real call.

This one I can't test in live, it costs real money with this behaviour, I'm unable to create a working order with forceOpen set to true, and the behaviour without it is as per false, despite the documentation saying it's true. I can't find a workaround.

How do I get support on this from IG, and bugs fixed or ultimately debug how this is my problem? Having been a developer for way too many years I'm conscious you can be very confident in your code only to find out you did get something wrong. For me the code works perfectly, a fairly complex strategy, until I add in the "forceOpen": "true" and get the 400.

Or is this 'just how it is' with the IG API? Thanks!

Link to comment

5 answers to this question

Recommended Posts

  • 0
19 minutes ago, Tipper258 said:

Issue 1. The API does not behave as documented

The streaming API does not behave like the documentation, it never raises a WOU, always an OPU and it can have 2 different bodies. You have to inspect the body for presence of certain properties to determine what type of message it is. No biggie, can work round this once figured out this is what happens in both demo and live spread bet accounts.

Issue 2. forceOpen behaviour

Having used IG for many years, I'm very familiar with the web platform behaviour of forceOpen. Set it to true and your working order doesn't impact existing orders when the order executes. Set it to false and the order will apply to any open position in the same epic, quite how it decides which position to impact if you have multiple open is unknown.

In the REST API, the documentation says the default for forceOpen is true for working orders. Certainly if I try to set it to true I get a 400 with invalid.forceOpen error. If I don't set it, when the order is executed it behaves as if it were set to false and closes open positions which is rather unhelpful for the strategy.

When using the API companion, and I paste in the exact request body, with forceOpen set to true, it doesn't complain, off it goes and creates a working order. Mind you it returns the dealRef I specified but doesn't create the order with the dealRef which I guess is an implementation 'thing' with the companion, but then again that says maybe it actually strip out the forceOpen true before making the real API call too? Hard to know, or have confidence it's a true reflection of the real call.

This one I can't test in live, it costs real money with this behaviour, I'm unable to create a working order with forceOpen set to true, and the behaviour without it is as per false, despite the documentation saying it's true. I can't find a workaround.

How do I get support on this from IG, and bugs fixed or ultimately debug how this is my problem? Having been a developer for way too many years I'm conscious you can be very confident in your code only to find out you did get something wrong. For me the code works perfectly, a fairly complex strategy, until I add in the "forceOpen": "true" and get the 400.

Or is this 'just how it is' with the IG API? Thanks!

Hi @Tipper258,

The best way to get some support with API would be to reach out to webapisupport@ig.com.

All the best - Arvin

  • Like 1
Link to comment
  • 0

Hi @ArvinIG, I've written in with both bugs, not heard anything back yet, but I see you resolved something on another thread in a way which implied individual accounts need to be enabled to force open positions in opposite directions. 

If my demo account is not enabled for this, it could be a perfect explanation for the behaviour noted above. So I used the web interface and opened a position and then placed an opposing order, checking the 'open new position' box. It behaved impeccably, opening an opposing position when the price was hit. 

Guess that means my account can open opposing positions on the same epic via the web, any reason it wouldn't via the API?

Thanks

Link to comment
  • 0
5 minutes ago, Tipper258 said:

Hi @ArvinIG, I've written in with both bugs, not heard anything back yet, but I see you resolved something on another thread in a way which implied individual accounts need to be enabled to force open positions in opposite directions. 

If my demo account is not enabled for this, it could be a perfect explanation for the behaviour noted above. So I used the web interface and opened a position and then placed an opposing order, checking the 'open new position' box. It behaved impeccably, opening an opposing position when the price was hit. 

Guess that means my account can open opposing positions on the same epic via the web, any reason it wouldn't via the API?

Thanks

Stop the bus! I've just read that the API defaults to version 1 if not specified, and not as I'd assumed the latest version. Looking at the difference between the version specs, there is no forceOpen on v1, I need to explicitly set v2.

Tests under way with the appropriate header .....

Link to comment
  • 0

In case anyone reads this in the future, the root cause was the API call to POST an order did not specify the API version in the headers, which then defaults to v1. It is API v2 that supports the needed forceOpen behaviour, adding that header resolved the issue 2 above.

  • Like 1
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • image.png

  • Posts

    • Bitcoin: Anticipated target lies within the 58-60 range before an impending correction. The upward trajectory is displaying signs of softening, prompting short-term traders to elevate their stop-loss levels. Bond Yields: The 10-year yields are poised to conclude wave v) of C of (B). This development is pivotal as it will uphold the strength of the Dollar DXY. Consequently, positions in gold or silver should be refrained from until yields and the Dollar reach their peaks. China's Influence: An intriguing facet of the market landscape revolves around China. I've been meticulously observing a substantial Elliott Wave Triangle pattern dating back to 2008, which now seems to have reached its culmination. This event is forecasted to bolster base metal prices, particularly once the Dollar and yields reach their zeniths. Crude Oil: Progressing steadily on its upward trajectory, crude oil is set for further ascension. Natural Gas: The recent uptick in natural gas prices is construed as a corrective rally, indicative of an impending shorting opportunity in the near future. Video Chapters 00:00 Bitcoin (BTC) 07:41 US Dollar Index, DXY / TLT Bonds. US Gov Bonds 10 Yr Yields 12:58 Precious Metals: Spot Gold XAU /GDX ETF / US Spot Silver XAG  16:37 Base Metals: Iron Ore, Copper XCU/USD. Uranium URA ETF / China 24:07 Energy: Crude Oil WTIOIL / Natural Gas NG 27:57 End Analyst Peter Mathers TradingLounge™ Australian Financial Services Licence - AFSL 317817 Source: tradinglounge. com  Join & Learn Elliott Wave from Experts Stay ahead of market movements and make informed decisions with our comprehensive analysis.  
    • The emergence of ICO and NFTs ushered in tokens as speculative assets. These were really attached with no use-cases beyond defi and collectibles. The next wave of tokenization seeks to bring forth experiences and token applications. These are set to be programmable and filled with user centric integration points. Smart tokens are set to usher in digital transformation, by bringing a paradigm shift from websites, to apps and to tokens. Tokenized services are set to transform user experience by rendering services where and when a consumer needs them. The core intent of the smart layer network is to bring real life use-cases to Web3, the project’s team firmly believes that, by infusing useable features into Web3 it will undoubtedly usher it mainstream. Critically looking at Smart Layer would expose that, after carefully and critically analyzing the existence of different token models, it is found that, there is truly no worthwhile use-case, thus the project seeks to curb the conundrum. In a bid to get a grasp of what smart tokens are, view it through the lens of how websites firstly started rendering digital services, then slowly evolving to apps. With Smart Layer, the focus is to empower tokens to do what websites and apps had hitherto done. The erstwhile services offered are set to be tokenized thus allowing them to be delivered when and where the consumer needs them and without requiring direct integrations. The Smart Layer Network native token $SLN is slated to be listed on bitget upon the satisfaction of certain criterion and prerequisite, deposit is however is currently opened. By depositing it on the CEX, the listing will be enabled and the token cast into further spotlight.  
×
×
  • Create New...
us