During testing with Postman, we observed the following behavior:
We modified a task at 17:29 and then called the API with modified_at.after=2026-01-28T17:28:00.000Z.
For approximately the first 10 minutes after the update (17:29–17:39), the API response was inconsistent — sometimes it returned the modified task, and sometimes it returned an empty result.
After about 10 minutes, the response became consistent and always included the modified task.
This behavior is impacting our system and blocking subsequent processing steps.
Could you please help us understand why this happens and whether this delay is expected behavior?
Thanks for flagging this. I ran a few tests on my side and can confirm that the time it takes for results to become consistent can be longer than what’s currently mentioned in our documentation. Since it’s not clear whether this delay is fully expected, I’m going to follow up with the team that owns this feature to confirm the intended behavior and see whether we should update the docs or improve anything on our end.
As noted in the API Reference, this endpoint is eventually consistent, which means it isn’t well suited for time-sensitive use cases that require immediate updates after a write. If you need the most up-to-date data right away, I recommend using one of the Tasks API endpoints that read directly from the primary data store, such as:
If you need additional sorting or filtering, the best approach is to apply client-side logic based on the modified_at field.
Sorry for the inconvenience this has caused. Due to the nature of the Search Tasks endpoint—which relies on advanced indexing and optimization across the entire workspace—we can’t guarantee immediate consistency after write operations.
I heard back from the team, and I’m afraid there isn’t much we can change on this behavior right now. Task indexing after updates happens asynchronously and depends on the current load on the system. Under normal conditions, the process typically completes in <60 seconds, but during periods of high traffic it can take several minutes. This is why we generally don’t recommend this endpoint for use cases that require immediate consistency.
I also ran several tests after your report, and in my environment I was consistently able to get up-to-date results after ~10 seconds, which suggests the longer delay you observed may have been caused by temporary load at that time.
Looking at your screencast, it seems you’re primarily filtering tasks based on the modified_at field. In this case, I’d strongly recommend using the Get multiple tasks endpoint with the modified_since parameter instead. This endpoint reads directly from the primary data store and returns consistent results, so you won’t need to add any additional safeguards or delays to account for indexing latency, as you would with the search endpoint.
Just to add an anecdotal datapoint, I just did my monthly Asana AMA for nonprofits and updated a task after creating a dashboard chart and expected it would be a little while before we could see the results, but it appeared in about 5 seconds–I was prepared to take another question and come back for it, but not necessary!