{"_id":"58a363deb2c9e91b00e551d4","initVersion":{"_id":"55773a5ba042551900b002ce","version":"1"},"project":"55773a5ba042551900b002cb","user":{"_id":"546d17e2eb9cfd1400dd4529","username":"","name":"Gareth Davies"},"__v":0,"createdAt":"2017-02-14T20:09:02.454Z","changelog":[],"body":"The [2017 Cape Town ITU Triathlon World Cup](http://www.triathlon.org/events/event/2017_cape_town_itu_triathlon_world_cup) held on Feb 11th 2017 marked the first time that the [new version of the live timing standard](https://developers.triathlon.org/v1/page/live-timing-standard-v11) was used.  Whilst this results in an improved timing interface on [Triathlon.org](http://www.triathlon.org/live) the major implication of this is that API users can receive real-time timing data directly for use in their own applications.\n\nThere are current three ways to receive live timing data:\n\n### 1 - REST API\n\nLive timing data is available via the [Live Timing endpoint](https://developers.triathlon.org/docs/live-timing) by specifying the `prog_id` of the race that you wish to get timing for i.e. `live/timing/{prog_id}`. This endpoint will respond with the latest available timing message. Note that the  `prog_id` of the timing may be determined from either receiving a real-time feed (see below) or from the [Program Listings](https://developers.triathlon.org/docs/program-listings) endpoint for a given event. Whilst this is an ideal solution for obtaining an initial timing state polling this endpoint is not recommended for real-time applications.\n\n### 2 - WEBHOOK FEED\n\nThe live timing webhook feed is part of the [Subscription API](https://developers.triathlon.org/docs/subscriptions-api-overview) where API users may subscribe a URL to receive all `timing.store` events. Currently to register a subscription, simply go to the [API management portal](https://apps.api.triathlon.org/login) and register a subscription via the form as shown below.\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/be4d451-create_subscription.png\",\n        \"create_subscription.png\",\n        1180,\n        788,\n        \"#0a5f9d\"\n      ],\n      \"caption\": \"\"\n    }\n  ]\n}\n[/block]\nNow when any timing messages are received they are immediately proxied to the URL specified such that subscribers may receive the real-time updates and process and deliver messages according to their application's requirements. Timing data is included in a `payload` object as shown below and a full timing message is delivered.\n\n```\n{\n\"subscription\": \"timing.store\",\n\"payload\": {\n\t\"date\": \"2017-02-11T14:34:28.917Z\",\n\t\"start_time\": \"2017-02-11T15:30:00.000Z\",\n\t\"event_id\": \"109656\",\n\t\"event_name\": \"2017 Cape Town ITU Triathlon World Cup\",\n\t\"prog_id\": \"281501\",\n\t\"prog_name\": \"Elite Men\",\n\t\"wetsuit\": \"true\",\n\t\"sandbox\": \"true\",\n\t\"num_athletes\": \"34\",\n\t\"status\": \"live\",\n\t...\n```\n\n### 3 - STREAMING API\n\nA websocket feed is available at `wss://socket.api.triathlon.org/timing` which sends all timing messages over a websocket channel so front-end applications can be directly updated. Split data is not included in the websocket feed for brevity of the messages and so full timing messages may be obtained from either then webhook feed or from the REST API when a new timing message is received.\n\n## Implementation of the Live Timing Feed\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"For full details of each of the items in the timing messages you should consult the timing standard\",\n  \"body\": \"Importantly every message contains **full** timing information such that receiving the _latest_ timing message is all you need.\"\n}\n[/block]\nIf you wish to subscribe to future timing feeds then you should take note of how the timing messages are sent:\n\n* An initial start list message will be published once the start lists have been confirmed. This will detail the start time, the `event_id` and `prog_id` as well as containing the data for each athlete on the start list (you may use the `athlete_id` to get further information for each athlete from the [Athletes API](https://developers.triathlon.org/docs/athletes-api-overview)).\n\n* Any changes to the published start times, condition information or any DNS (indicated in the `athlete.status` field) will be indicated by a new timing message. Any messages sent prior to the start of the race will be indicated by a status of `prerace`.\n\n* As soon as the race begins the `start_time` containing the accurate start time will be published and the status will be updated to `live` indicating that the race is underway.\n\n* As soon as the first athlete crosses the first timing point the `latest` block will be updated to include the details of the segment (i.e. `segment_id` and `segment_name`) as well as how many athletes have crossed the timing point (which may be used to create leaderboards). Whilst timing messages are pushed whenever there is new data, on occasions timing messages will be combined into a single message e.g. a bike pack crossing a timing point will not have a message for each athlete. As each timing message always contains full timing information you should simply act on the latest message received.\n\n* This process continues through each segment of the race with the `latest` block always indicating the latest timing point. Any athlete that withdraws from the race should have their status updated to `DNF`. \n\n* Once the race has finished and the results are confirmed a final message with a status of `official` will be published.\n\nIf you only want to receive the full timing data at the end of the race (i.e. all the lap data) you may simply make a request to the REST API endpoint upon conclusion of the race and the timing message will contain all available data.\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"This feed is considered a beta release\",\n  \"body\": \"This feed should currently be considered as a beta release primarily as due to the nature of working with a multitude of different timers it is difficult to guarantee consistency. However you are free to take the feed and we would [love your feedback](http://slack.developers.triathlon.org/).\"\n}\n[/block]\nAll ITU sanctioned events are free to implement the [live timing standard ](https://developers.triathlon.org/v1/page/live-timing-standard-v11) and then timing information will be made available via the API. However, at present only [World Triathlon Series](http://www.triathlon.org/events#q=&hPP=15&idx=events&p=0&dFR[event_categories.cat_name][0]=World%20Triathlon%20Series&dFR[year][0]=2017&is_v=1) and certain [World Cup](http://www.triathlon.org/events#q=&hPP=15&idx=events&p=0&dFR[event_categories.cat_name][0]=World%20Cup&dFR%5Bsport.cat_name%5D%5B0%5D=Triathlon&dFR[year][0]=2017&is_v=1) events should be expected to provide the live timing data.","slug":"live-timing-2017","title":"Live Timing 2017"}

Live Timing 2017


The [2017 Cape Town ITU Triathlon World Cup](http://www.triathlon.org/events/event/2017_cape_town_itu_triathlon_world_cup) held on Feb 11th 2017 marked the first time that the [new version of the live timing standard](https://developers.triathlon.org/v1/page/live-timing-standard-v11) was used. Whilst this results in an improved timing interface on [Triathlon.org](http://www.triathlon.org/live) the major implication of this is that API users can receive real-time timing data directly for use in their own applications. There are current three ways to receive live timing data: ### 1 - REST API Live timing data is available via the [Live Timing endpoint](https://developers.triathlon.org/docs/live-timing) by specifying the `prog_id` of the race that you wish to get timing for i.e. `live/timing/{prog_id}`. This endpoint will respond with the latest available timing message. Note that the `prog_id` of the timing may be determined from either receiving a real-time feed (see below) or from the [Program Listings](https://developers.triathlon.org/docs/program-listings) endpoint for a given event. Whilst this is an ideal solution for obtaining an initial timing state polling this endpoint is not recommended for real-time applications. ### 2 - WEBHOOK FEED The live timing webhook feed is part of the [Subscription API](https://developers.triathlon.org/docs/subscriptions-api-overview) where API users may subscribe a URL to receive all `timing.store` events. Currently to register a subscription, simply go to the [API management portal](https://apps.api.triathlon.org/login) and register a subscription via the form as shown below. [block:image] { "images": [ { "image": [ "https://files.readme.io/be4d451-create_subscription.png", "create_subscription.png", 1180, 788, "#0a5f9d" ], "caption": "" } ] } [/block] Now when any timing messages are received they are immediately proxied to the URL specified such that subscribers may receive the real-time updates and process and deliver messages according to their application's requirements. Timing data is included in a `payload` object as shown below and a full timing message is delivered. ``` { "subscription": "timing.store", "payload": { "date": "2017-02-11T14:34:28.917Z", "start_time": "2017-02-11T15:30:00.000Z", "event_id": "109656", "event_name": "2017 Cape Town ITU Triathlon World Cup", "prog_id": "281501", "prog_name": "Elite Men", "wetsuit": "true", "sandbox": "true", "num_athletes": "34", "status": "live", ... ``` ### 3 - STREAMING API A websocket feed is available at `wss://socket.api.triathlon.org/timing` which sends all timing messages over a websocket channel so front-end applications can be directly updated. Split data is not included in the websocket feed for brevity of the messages and so full timing messages may be obtained from either then webhook feed or from the REST API when a new timing message is received. ## Implementation of the Live Timing Feed [block:callout] { "type": "info", "title": "For full details of each of the items in the timing messages you should consult the timing standard", "body": "Importantly every message contains **full** timing information such that receiving the _latest_ timing message is all you need." } [/block] If you wish to subscribe to future timing feeds then you should take note of how the timing messages are sent: * An initial start list message will be published once the start lists have been confirmed. This will detail the start time, the `event_id` and `prog_id` as well as containing the data for each athlete on the start list (you may use the `athlete_id` to get further information for each athlete from the [Athletes API](https://developers.triathlon.org/docs/athletes-api-overview)). * Any changes to the published start times, condition information or any DNS (indicated in the `athlete.status` field) will be indicated by a new timing message. Any messages sent prior to the start of the race will be indicated by a status of `prerace`. * As soon as the race begins the `start_time` containing the accurate start time will be published and the status will be updated to `live` indicating that the race is underway. * As soon as the first athlete crosses the first timing point the `latest` block will be updated to include the details of the segment (i.e. `segment_id` and `segment_name`) as well as how many athletes have crossed the timing point (which may be used to create leaderboards). Whilst timing messages are pushed whenever there is new data, on occasions timing messages will be combined into a single message e.g. a bike pack crossing a timing point will not have a message for each athlete. As each timing message always contains full timing information you should simply act on the latest message received. * This process continues through each segment of the race with the `latest` block always indicating the latest timing point. Any athlete that withdraws from the race should have their status updated to `DNF`. * Once the race has finished and the results are confirmed a final message with a status of `official` will be published. If you only want to receive the full timing data at the end of the race (i.e. all the lap data) you may simply make a request to the REST API endpoint upon conclusion of the race and the timing message will contain all available data. [block:callout] { "type": "warning", "title": "This feed is considered a beta release", "body": "This feed should currently be considered as a beta release primarily as due to the nature of working with a multitude of different timers it is difficult to guarantee consistency. However you are free to take the feed and we would [love your feedback](http://slack.developers.triathlon.org/)." } [/block] All ITU sanctioned events are free to implement the [live timing standard ](https://developers.triathlon.org/v1/page/live-timing-standard-v11) and then timing information will be made available via the API. However, at present only [World Triathlon Series](http://www.triathlon.org/events#q=&hPP=15&idx=events&p=0&dFR[event_categories.cat_name][0]=World%20Triathlon%20Series&dFR[year][0]=2017&is_v=1) and certain [World Cup](http://www.triathlon.org/events#q=&hPP=15&idx=events&p=0&dFR[event_categories.cat_name][0]=World%20Cup&dFR%5Bsport.cat_name%5D%5B0%5D=Triathlon&dFR[year][0]=2017&is_v=1) events should be expected to provide the live timing data.