Common Oversights when Implementing Validic
This article pertains to: Legacy API (V1)
No Paging Method
Often when developing and testing an implementation of Validic, result record counts are low and it seems like all data is being captured. When users begin to sign up and load increases, it becomes apparent that data is being missed, often due to data overflowing into another page that is not being requested. All of the data endpoints in the Validic API are subject to pagination including latest.json. Increasing the page size using the limit filter helps reduce the number of pages but does not guarantee all data will be returned in a single page.
References
Timestamp Handling
To get a complete picture of a when an activity occurred, it's important to apply the "utc_offset" to the "timestamp". Failure to do this can make it seem that activities occurred on a different day or even a future day.
References
Making latest.json Requests Too Infrequently
Latest.json was designed to retrieve near real time updates to data. It should be called at short intervals to prevent a large number of pages from being returned.
References
No Data Reconciliation
While under normal operating conditions all data transfers should be successful and complete, there may be circumstances where data was missed. It is important to have a mechanism in place, whether daily or weekly, that can capture a week or month's worth of data respectively, and check it against the data already received from Validic.
No Error Handling
Although Validic strives to maintain a high level of uptime, there may be instances where the Validic API is down momentarily. These instances are likely due to deployments and are generally very short. An integration to Validic should be able to recover from a 500 Internal Server Error for example, by implementing a retry mechanism.
Assuming Validic Modifies Data
Other than basic basic unit conversions, Validic does not modify data retrieved from app sources. While some fields are pretty straight forward, like calories, others are more complex in how they are calculated by the app. Our goal is to document as many of these intricacies and make them available in our support portal.
Marketplace Flow
The user's experience when connecting their app is often messy requiring the use of the browser navigation buttons or the browser's refresh button. The flow of connecting the app should be just as seamless getting back from the vendor's oAuth page as it is getting there. Once the user is returned, they should see some feedback on the actions they just made.
References