Hi all,
We’re planning to release the following OPU and WOU streaming changes for the Web API (November release - DEMO 7th, LIVE 14th):
1. dealReference is currently null on OPUs and WOUs and will now hold the client reference
2. channel is a new field and will enable client apps to understand if a trade was placed via the API or via the web/mobile apps.
3. timestamp is a new field and provides the server time when the OPU or WOU were triggered
4. dealId this field hasn’t changed and will hold the deal id of the working order or open position
5. dealIdOrigin this is a new field for OPUs which will hold the deal id of the originating order that has triggered the OPU – e.g. the deal id of a filled working order.
6. affectedDeal this field is officially not part of the API and has therefore not been documented on the streaming reference documentation. It is always null so we will remove it from OPUs and WOUs. Confirms will remain unchanged and will contain ‘affectedDeals’.
An OPU will look like this:
{
"stopLevel": null,
"limitLevel": null,
"guaranteedStop": false,
"expiry": "-",
"dealIdOrigin": "DIAAAAAPD5V84AS",
"size": 1,
"channel": "OSAutoStopFill",
"timestamp": "2015-10-19T12:41:36.000",
"status": "OPEN",
"epic": "CS.D.EURUSD.CFD.IP",
"level": 1.1337,
"direction": "SELL",
"dealReference": "VVQXREZB4ZP2ECP",
"dealStatus": "ACCEPTED",
"dealId": "DIAAAAAPD6H3UAP"
}
in this case dealIdOrigin (DIAAAAAPD5V84AS) refers to the working order deal id which has created this position (DIAAAAAPD6H3UAP). dealReference (VVQXREZB4ZP2ECP ) is the client reference that the user obtained when placing the working order.
As ‘affectedDeals’ will be removed from OPUs and WOUs, please ensure that you update your apps accordingly.
Please let us know if you have any questions.
Chris
Sounds good, except for
"timestamp": "2015-10-19T12:41:36.000"
Adding the time information is excellent but please use Unix timestamp format. Back in July you said yourself on a different matter that "Unix timestamps have been chosen as a sensible option and to make this consistent throughout the API." I hope improved consistency will be an ongoing ambition.
Hi APItrader,
Apologies if we didn’t communicate this clearly, but as part of the updates last August (http://labs.ig.com/node/294 - point 1) we eventually opted for ISO 8601 formatted dates rather than using timestamps in milliseconds. There is generally good support for parsing ISO formatted dates (e.g. joda datetime library in Java) and dates are now in UTC except otherwise stated.
Chris
Hmmmm, I seemed to have missed that somehow, sorry! ISO 8601 is fine, the important thing is consistency. Thanks!
GET /prices
has timestamps like
[snapshotTime] => 2016:02:16-11:30:00
Would it be possible to use ISO 8601 also here?
And, it would be great if you could either use UTC for timestamps consistently throughout the API, or, always include the timezone explicitly in all timestamps.
GET /prices
has timestamps like
[snapshotTime] => 2016:02:16-11:30:00
Would it be possible to use ISO 8601 also here?
And, it would be great if you could either use UTC for timestamps consistently throughout the API, or, always include the timezone explicitly in all timestamps.
Thanks for pointing me to version 3!
However, there is still room for better consistency. The input is not UTC (even though the documentation does not state otherwise).
If I call this endpoint with "from" set to "2016-02-18T02:30:00"
the first element returned includes
[snapshotTime] => 2016/02/18 02:30:00
[snapshotTimeUTC] => 2016-02-18T01:30:00
To add to the confusion ISO8601 is used for the input local time and the output UTC, whereas output local time uses a different format.
Using GET /positions (ver 2) I get, for example, this:
...
[createdDate] => 2016/02/18 16:59:50:000
[createdDateUTC] => 2016-02-18T16:59:50
...
Why are these the same? My local timezone is not UTC.