Latest endpoint vs. Push Notifications

This article pertains to: Legacy API (V1)

What is the difference between using the latest.json endpoint and push notifications?

The primary difference is that push notifications are intended for real time, individual user-level data delivery, while the latest.json endpoint is intended for near real time, bulk population-level data delivery. For large population sets, push notifications don’t always make sense, as your system could end up receiving thousands of push notifications per minute. Additionally, relying on push notifications alone is not recommended for a large scale, high availability setup.

The latest.json endpoint is a much more stable way to access data for a large population set. This call allows you to access all of the latest data in Validic between two timestamps.

Latest.json Best Practices

ATTENTION: This article has been updated to reflect a start_date of the previous end_date for requests to latest.json. Incrementing the end_date by one second for the next start_date will result in a loss of data for any record updated within that second.

A best practices implementation of /routine/latest.json calls would look something like this.

/routine/latest.json?start_date=2014-03-09T10:00:00Z&end_date=2014-03-09T10:05:00Z
/routine/latest.json?start_date=2014-03-09T10:05:00Z&end_date=2014-03-09T10:10:00Z
/routine/latest.json?start_date=2014-03-09T10:10:00Z&end_date=2014-03-09T10:15:00Z
/routine/latest.json?start_date=2014-03-09T10:15:00Z&end_date=2014-03-09T10:20:00Z
/routine/latest.json?start_date=2014-03-09T10:20:00Z&end_date=2014-03-09T10:25:00Z
/routine/latest.json?start_date=2014-03-09T10:25:00Z&end_date=2014-03-09T10:30:00Z
/routine/latest.json?start_date=2014-03-09T10:30:00Z&end_date=2014-03-09T10:35:00Z
/routine/latest.json?start_date=2014-03-09T10:35:00Z&end_date=2014-03-09T10:40:00Z
/routine/latest.json?start_date=2014-03-09T10:40:00Z&end_date=2014-03-09T10:45:00Z
/routine/latest.json?start_date=2014-03-09T10:45:00Z&end_date=2014-03-09T10:50:00Z

The benefit of this series of calls is that you ping Validic every five minutes (could be every 2 minutes, every 10 minutes, etc.) and you receive any updates that have been made for your organization in the specified time range. So for example, if a user doesn't sync her Fitbit for 5 days and then syncs it on 2014-03-09T10:47:39Z, Validic will return all of her Fitbit activities from the last 5 days in the last call in the series above.

NOTE: When specifying the end_date using this method, it is imperative that server times are synced to Validic's server times. In fact, adding a second or two delay ensures that the end_date requested is not a future date at the time the request is made. You may use the Date header returned by Validic to refer to.

Alternatively, if a latest.json request is made where end_date is not specified, the end_date we return in the summary of a latest call is a perfect candidate for the start_date of your next latest call. This will effectively remove the possibility of missing data using the latest call due to server time differences.

routine/latest.json?start_date=2016-01-14T13:52:01Z

{
    "summary":{
        "status":200,
        "message":"Ok",
        "results":0,
        "start_date":"2016-01-14T13:52:01+00:00",
        "end_date":"2016-01-14T13:52:24+00:00",
        "offset":0,
        "limit":100,
        "previous":null,
        "next":null,
        "params":{
            "start_date":"2016-01-14T13:52:01+00:00",
            "end_date":null,
            "offset":0,
            "limit":0
        }
    },
    "routine":[
        
    ]
}

Next latest request start_date

routine/latest.json?start_date=2016-01-14T13:52:24+00:00

NOTE: Using this method requires the response to be parsed. If requests are made in rapid succession, there is a slight possibility that the start_date will not have been received, parsed and saved before the next latest request is made resulting in the same data, along with new data, being returned again.