create working order: returned body

9 posts / 0 new
Last post
create working order: returned body


The request Create Working Order has this response:

"dealReference": "BLABLABLA"

Later on, when one wants to change/delete the working order, the relevant information is "dealId"
Those 2 are not the same.

The only way to retrieve that is to do a getworkingOrders request. Or am I missing something?

Can the createworkingorderresponse already include the "dealId" ?

Re: create working order: returned body

Hi finjulhich

If you subscribe to Confirms, OPU (open positions update) and WOU (working orders update), this will stream any updates to your trades and working orders, with the relevant dealID. You can then capture this for any amendments etc.

Hope that helps


Indeed, after the Create

Indeed, after the Create Working Order respondig with {'dealReference': 'HZNF24JMAPK24H9'}, I get:

1. a WOU
{ 'dealReference': None, 'dealStatus': 'ACCEPTED', 'dealId': 'DIAAAAA7GHVT4AD', 'status': 'OPEN' }

2. and then a CONFIRM:
{ 'dealStatus': 'ACCEPTED', 'status': 'OPEN', 'reason': 'SUCCESS', 'limitDistance': None, 'direction': 'SELL', 'affectedDeals': [{'status': 'OPENED', 'dealId': 'DIAAAAA7GHVT4AD'}], 'dealReference': 'HZNF24JMAPK24H9'}

Is there a guaranteed order of WOU first then CONFIRM second?
Do you know why dealReference is None in the WOU. This complicates the logic of my system.
My system wants to be aware of orders I sent through the web platform too...
For orders entered on the web platform, I receive WOUs.
The logic so far is, if I know about the the dealId in the WOU, then it's an exisiting order, otherwise, it's a new order and I never knew about it before.
Now with orders that my systems send itself, if I save the dealReference, it still doesn't help me with the WOU to know that that's the order I sent myself. The CONFIRM does, but not the WOU.

I tried to implement this. On

I tried to implement this. On reception of a WOU:

I would do a CONFIRMS REST API request, but that comes back with Not found for the dealref I obtained from my createworkingorder request. It seems the CONFIRMS REST request is for actual trades (positions opened).

Can the WOU have a dealReference set instead of null ?

create working order: returned body

Hi finjulhich,

There is no guaranteed order of WOU first then CONFIRM second. We do return confirms for creating workings orders, can you please send a deal ID via the contact us section, and we can check the logs.

Please note there is currently a bug being looked at with the dealReference. We are also adding originating deal id/deal references to OPU messages to enable applications to link WOU and OPU messages. This will hopefully simplify things and should be rolled out within the next few weeks.


Yes I do receive confirms for

Yes I do receive confirms for create working order. The problem is when I receive WOU first, which doesn't have dealreference, I think it's an order created by the dealing platform rather than by system. And that's the problem
Once you fix the dealreference in the WOU message, then all will be fine.
Thanks, let us know when this is deployed.

and just to reiterate, are

and just to reiterate, are you saying, if I send a REST /confirms/{dealref} request with a dealref that I just received from "create working order" request, it should find it?

create working order: returned body

Hi finjulhich,

The deal reference is generated and returned when the order is received by the IG, whilst the deal ID is generated by the execution engine that handles the order. The confirmation is generated as the last part of the execution flow, via a message from the execution engine.

The confirmation is published to Lightstreamer and is also cached for around one minute. The best solution is to use Lightstreamer to subscribe to confirmations and to use the aforementioned endpoint if the confirmation doesn't appear after a couple of seconds - this is the strategy used by IG apps. The endpoint will return a 404 if the cache doesn't contain the confirmation - which might be that:

- the confirmation hasn't been received from the execution engine
- it is currently being transformed from its internal raw form into the confirmation message and so hasn't been published and cached
- it has been deleted from the cache.

We'd encourage use of Lightstreamer because of it high performance and its high concurrency!

Hope that helps.


404s on confirms

Sorry to resurrect such an old thread. I've an app that manages positions and orders based on SMS texts from a tipster service - and no it doesn't seem to be a money spinner before anyone asks :) but it was a great exercise writing it, completely in javascript and running a serverless functions on AWS. That last piece is really important, it means I pay nothing for having the app deployed and listening, and only for when a message is received. A great strategy for a low volume workload.

I am however suffering from the 404s mentioned above I believe. After closing a position, or sometimes amending one, the confirm gets a 404. Completely understand the systems aren't atomic and there's a race condition between my app asking for the confirm and IG systems flowing the position change through theirs. Is there any option other than lighstreamer subscriptions? It's doable, a shed load more code, and care will be needed to implement to avoid chatty traffic ramping up costs at AWS.


Log in or register to post comments