No More Polling the Whole Database – Fetch Changes Easily with API 3.3-beta!

With our latest release of 7pace Timetracker, we are pleased to announce a brand new API version – v3.3-beta. API v3.3-beta comes with significant improvements within our extensively-used OData Reporting API. 

A big ask from our 7pace Timetracker users has been the ability to track changes made to their worklogs over a specific period of time. Fetching all records and comparing them with the previous state to understand what records were deleted, changed, or added, has long been the only way for our customers to track changes made to their worklogs over a specific period of time. Not anymore! By introducing two enhancements, we now allow users to view all changes (“delta data”) without polling the entire history.

So first, enhancements were made on the editedTimestamp. The editedTimestamp is always updated when changes are made to a worklog. This was already implemented on many existing events, but now, all events (for example, when the billable flag, billable hours, budget or activity type is changed on the Times Explorer page) will update the editedTimestamp. With this new enhancement in API 3.3-beta, instead of repeatedly polling the entire history of data, you can now query just the data that was changed during a specific period. 

An even bigger change that we implemented in our most recent API version is “soft delete”. We’re not making any changes to the 7pace Timetracker UI itself; deleted worklogs will still not be visible anywhere in the system and all existing integrations, reporting widgets and exports will also only return active (not deleted) worklogs like before. But with this update, worklogs that are deleted by 7pace Timetracker users will now be specifically marked as deleted in the database rather than permanently removed (a new field “IsDeleted” has been added to ReportingWorkLog and will always be present in any OData API requests that are executed using version 3.3-beta). Prior to this, our users were required to frequently query all worklogs and compare the differences to identify any deletions. (Please note: currently, there is no way to get only deleted worklogs). You can find out more information on this within our API documentation library.

We’re rolling out this feature gradually. Once fully rolled out, we will mark the 3.3-beta version as stable; this may take a few weeks, but rest assured that our beta version is good to go for production usage. We may even expand this change to different APIs (like REST API) in the future if there is a demand for it. 

These improvements make it much quicker and easier for you to view changes to your team’s worklogs and setting up incremental refresh without having to rely on numerous and often cumbersome API requests that bog down the system of all users. It’s a win win!

If you have any questions or feedback, please let us know in the comments, below.