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

    • Recently, U.S. Senator Bill Hagerty from Tennessee spoke at the Bitcoin conference, stating his efforts to push for Bitcoin-supportive legislation to promote freedom and opportunity. This year, cryptocurrency has become a key battleground in the election campaigns. It remains to be seen whether future policies on cryptocurrency will improve.
    • The digital landscape is undergoing a profound transformation as attention, once a freely given commodity, is increasingly recognized as a valuable asset. Layer3 is at the forefront of this revolution, pioneering a new economy where attention can be owned, traded, and monetized   This innovative approach empowers individuals to monetize their engagement, providing unprecedented control over personal data. Simultaneously, advertisers benefit from transparent metrics that optimize campaign performance. Content creators are presented with diverse revenue avenues beyond traditional advertising, while the overall ecosystem experiences a more equitable distribution of value.   The implications of Layer3 extend across various sectors. Social media platforms, for instance, can leverage this technology to revolutionize user engagement and monetization strategies. Tokenomics play a crucial role in driving Layer3's economy, incentivizing participation and rewarding value creation. While challenges such as data privacy and market volatility exist, the potential benefits of Layer3 are immense   Anticipation is building as its native token $L3 is on Bitget Pre-market as users await its listing on the exchange. This milestone is expected to significantly increase the token's visibility and accessibility, potentially driving substantial growth and attracting new investors. As the countdown begins, the crypto community watches with keen interest, eager to see how Layer3 will perform in this new chapter.
    • I've been exploring the world of play-to-earn gaming recently, looking for something that's not just about endless grinding but actually offers a fun and rewarding experience. OGC really stood out to me because it combines gaming with a sense of community in a unique way. OGC isn't just a game; it's a platform where you can play, earn, and even help shape its future. You're not just a player; you're part of a community with a voice. The idea of earning crypto while playing games is exciting, but what makes OGC special is its focus on community involvement. Your feedback can directly influence the development of the game, which is a big deal. I've also heard that the OGC token is available for pre-market trading on Bitget. While I'm still getting to know the platform and its features, it's definitely something to keep an eye on. Has anyone else tried OGC? What has your experience been like? I'd love to hear your thoughts and any tips you might have.
×
×
  • Create New...
us