First_timestamp for search/time_entries behaves incorrectly

Tech Discussions
, ,
1

The detailed reports POST search/time_entries endpoint appears to want to allow the use of a parameter first_timestamp, but this parameter doesn’t appear to work as expected.

Here’s what I’m seeing:

1 - Call the endpoint

curl -v -X POST https://api.track.toggl.com/reports/api/v3/workspace/<WID>/search/time_entries  \
  -H "Content-Type: application/json"  \
  -d '{"start_date":"2026-02-25","page_size":1,"order_by":"last_update"}'  \
  -u <TOKEN>:api_token | jq

This returns a single result (as expected), out of two total results in my workspace, limited by page_size. So far so good.

I also see these headers (among others):

x-next-id: 4306504544
x-next-row-number: 2
x-next-timestamp: 1772042400

But now the weird part… if I now do the following curl request - adding the first_timestamp from the header above - I get zero results:

curl -v -X POST https://api.track.toggl.com/reports/api/v3/workspace/<WID>/search/time_entries  \
  -H "Content-Type: application/json"  \
  -d '{"start_date":"2026-02-25","page_size":1,"order_by":"last_update","first_timestamp":1772042400}'  \
  -u <TOKEN>:api_token | jq

Shouldn’t I get more than zero results?

2

This sounds like an issue with how the first_timestamp parameter is being applied in the search/time_entries endpoint. Based on what you’re describing, it appears the parameter may not be filtering results as intended when used with your pagination headers.

This is not currently documented behavior in the knowledge base, which suggests it may be a bug or unexpected behavior in how the API handles this parameter. The fact that you’re getting zero results when using the x-next-timestamp value seems incorrect, especially since you should be able to continue retrieving subsequent pages of results.

I’d recommend trying a few things to work around this:

  1. Instead of using first_timestamp, try using the x-next-id parameter for pagination, which may be more reliable for continuing through your result set.

  2. Verify that the timestamp format and value you’re passing matches exactly what’s returned in the header.

  3. Consider whether adjusting your start_date or other filter parameters might help isolate whether this is specific to the timestamp parameter or a broader issue.

That said, the behavior you’re experiencing does appear to be unexpected, and this would be worth investigating further to determine if there’s an issue with how the endpoint processes the first_timestamp parameter.