I need to retrieve records where entered_on = 2025-08-06 from the API response. However, upon reviewing the API documentation, I found no query parameter available to filter by entered_on. Could you please guide me on how to fetch this data?
Hey @NagendraPrasad_G_T, Asana’s API unfortunately doesn’t have a direct query parameter for filtering by entered_on — it’s not one of the supported search fields.
The usual approach is:
-
Use the API to fetch a broader set of records (e.g., tasks, stories, or time tracking entries) that cover the date range you care about.
-
In your own code, filter the results locally by checking the entered_on field for 2025-08-06.
If you’re working with large datasets and want to minimize API calls, you could use available date filters like created_at, completed_at, or modified_since (depending on the object type) to narrow down the results before doing the entered_on filter on your end.
So in short — there’s no server-side filtering for entered_on yet, so you’ll need to handle it client-side after pulling the data.
Could you please let me know the correct query parameter for filtering by created_at?
I couldn’t find it mentioned in the documentation, but I need it to retrieve time entries for a specific date range.
Kindly share the parameter I should use to achieve this.
Thanks for the update. Two issues on my end:
-
The
time_entriesendpoint doesn’t exist—I’m usingtime_tracking_entriesinstead. -
Filtering with
created_at.beforeandcreated_at.afterisn’t returning the expected results.
Example I tried:
GET /time_tracking_entries?created_at.after=2025-08-01T00:00:00Z&created_at.before=2025-08-06T23:59:59Z
This still returns entries outside that range.
Could you confirm the correct endpoint and the exact query parameter names/syntax for filtering by created_at (including expected formats and timezone handling)?
It looks like the /time_tracking_entries endpoint is correct, but unfortunately, Asana doesn’t support filtering directly by created_at via query parameters. That’s why created_at.after and created_at.before aren’t working as expected.
The practical way to handle this is:
1. Fetch the entries: Call /time_tracking_entries without date filters.
2. Filter locally in your code: Once you have the data, filter the entries based on created_at. Make sure to handle time zones correctly (Asana uses ISO 8601, e.g., 2025-08-01T00:00:00Z).
Example in Python:
from datetime import datetime
import requests
start = datetime.fromisoformat(“2025-08-01T00:00:00+00:00”)
end = datetime.fromisoformat(“2025-08-06T23:59:59+00:00”)
response = requests.get(“https://app.asana.com/api/1.0/time_tracking_entries”)
entries = response.json()[‘data’]
filtered = [
e for e in entries
if start <= datetime.fromisoformat(e\['created_at'\].replace("Z", "+00:00")) <
= end
]
print(filtered)
Still if the code doesn’t work, I’m forwarding this to @Asana_Forum so that they can assist you.
Hi! To find out what I can do, say @asana_forum display help.
This code will not work (requests call is missing a bunch of params) and also won’t do what @NagendraPrasad_G_T wants it to. It also won’t handle pagination or errors, which will be critical for polling this much data.
I’m fairly certain that endpoint currently supports filtering for task, attributable_to, portfolio, and user. I tested with just putting in your org ID and it threw an error, that would probably be a better solution if possible. Depending on the scale of your org, you’ll probably want to either grab all relevant projects or users, then loop through either of those and GET their time tracking entries, then filter on your side for the entered_on property (created_at is the date the entry was created, not the date it was applied to).
If the number of time_tracking_entries is large, the API ends up making multiple calls to fetch data for a specific date. Please consider adding a query filter for entered_on, as this would help optimize the process and be beneficial for many users.
@NagendraPrasad_G_T - if you use one of the client libraries, it’ll handle the pagination for you (you can also handle this yourself if you want). I do agree that a better long-term solution would be to enable more filtering in query params.