Jump to content

Tipper258

Community Member
  • Posts

    8
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Tipper258

  1. 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.
  2. 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 .....
  3. 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
  4. 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!
  5. How does one file a bug in the API behaviour please, when it's not as per the documentation? "tested" this in production and it's the same behaviour, messages that have the structure of a WOU are being published as OPUs, as well as real OPUs. To work around you have to test for presence or absence of various properties in the json structure to derive which message type it's supposed to be.
  6. Hi, thanks for this, I'm guessing that the API reference is what I should expect to happen, although testing assumptions before having to test with real money would have been nice. If anyone has examples of the CONFIRM, WOU, and OPU messages involved for a trade flowing through I'd be very grateful.
  7. Folks, back at the API after a few years away .... in the demo account, when an order is placed, I would expect to see CONFIRM and WOU messages. Instead no CONFIRM, only OPU messages. This is for orders raised on the web platform (trying to understand behaviours before coding order / position mgmt). Can anyone confirm, or have a blog post anywhere on what messaging is generated in the stream for order and position lifecycle please? i.e. when an order is confirmed, order updates, conversion to a position, position updates, closing messages and so on. TIA, Alan
×
×
  • Create New...
us