Updates to the API - November

9 posts / 0 new
Last post
Chris
Updates to the API - November

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

APItrader
Sounds good, except for

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.

Chris
Updates to the API - November

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

APItrader
Hmmmm, I seemed to have

Hmmmm, I seemed to have missed that somehow, sorry! ISO 8601 is fine, the important thing is consistency. Thanks!

APItrader
GET /prices

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.

APItrader
GET /prices

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.

Chris
GET /prices
Hi APItrader, The latest price history endpoint (version 3) http://labs.ig.com/rest-trading-api-reference/service-detail?id=198 Should return the ISO formatted UTC timestamp: "snapshotTime": "2016/01/06 08:01:00", "snapshotTimeUTC": "2016-01-06T08:01:00", Hope this helps! Chris
APItrader
Thanks for pointing me to

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.

APItrader
More time confusion

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.

Log in or register to post comments