Native Time Tracking read data


Thanks for the useful thread. As many people, I also need to compute the cash burn base on timeline. Indeed, I need to track traversal tasks like “intern call”. The stake of time tracking according to me, it’s to identified project that will go out of the budget (in terms of human days) and daily duty that take time and cost money to the company.

With those kinds of details, we could have good discussion like doesn’t it normal that we spend more time on “intern call” this month.



Hey @sasha_f . Just adding my similar interest as @Matthias_Weber , @Diego_Fraga_C, @Anton_Kartsev and @anon24654219 in having access to user by user actual_time_minutes, rather than the summation. Our use case entails being able to check availability (capacity minus actuals) of resources team by team, and individual by individual. Loving the new native time tracking so far though


A post was split to a new topic: Connect Asana timer and Harvest

Just wanting to echo the use case for individual time entries. That would be huge!

Thanks Asana team for this great feature!!



Hello, I tested the module time tracking for 1 week now. Here some feedback regarding the feature:

  • the time tracking details is not accessible through the API (plan in roadmap)
  • the employee does have summary view : Indeed, I would like to know if I enter my weekly time, I couldn’t know that. Thus, if I missed tracking of one day, I could have a reminder or a view to see that miss. The best is to have a calendar view of the time tracked
  • We could set the maximum time entered by day. Indeed, the employee has to respect hour time.

For information, we use the time tracking to track daily task. We know we twist the product, yet it’s a general topic on the company to measure the cash burn according to the employee time tracking. We thought that ASANA is the good product to do that.

Thank a lot,


Hi @Kévin_TEMIN,

It’s best if you post this feedback in the Tips and Tricks forum section. It won’t be seen here by anyone except third-party developers (and the Asana Developer Relations team).

I really hope that it will be possible to access the track objects. It would be great. The sum of minutes does not provide the benefit that detailing by day would.


Hey folks, we’re going to be launching time tracking writes and finer-grained data soon! [Launched] Time Tracking Entries


CC: @sasha_f @Phil_Seeman

Hey, I’m using your node.js library to get the tasks and related (actual_time_minutes, estimated_time) fields. I can see the estimated_time inside the custom fields, but the actual_time_minutes field doesn’t exist in the task object. I’m sure I’m requesting that field, is there something wrong with the npm library?


Hi @Nairi_Haroutiounian,

I am assuming you are using our current node-asana client library (npm) and not our node-asana-preview client library (npm).

If you call our Get a task endpoint it should return the full task object with the data in the task schema which should include actual_time_minutes

This would be how you would make that call:

const asana = require('asana');

const client = asana.Client.create().useAccessToken("<PERSONAL_ACCESS_TOKEN>");

    .then((result) => {

Here’s what that would look like using our opt_fields query param (this should only return actual_time_minutes + gid):

const asana = require('asana');

const client = asana.Client.create().useAccessToken("<PERSONAL_ACCESS_TOKEN>");

client.tasks.getTask("<TASK_GID>", {opt_fields: "actual_time_minutes"})
    .then((result) => {

If you are calling our Get multiple tasks endpoint it will return a compact version of a task which will not have actual_time_minutes to request for that you must specify it in the opt_fields query param.

const asana = require('asana');
const client = asana.Client.create().useAccessToken("<PERSONAL_ACCESS_TOKEN>");

client.tasks.getTasks({project: "<PROJECT_GID>", opt_fields: "actual_time_minutes"})
    .then((result) => {
        console.log(JSON.stringify(result["data"], 0, 2));

Let us know if this helps or if you are making a different API call.

NOTE: The sample code above is using the latest version of our node-asana client library v1.0.2


Thank you for the response.

This is the options object:

  opt_expand: 'id,dependencies,due_on,due_at,assignee,tags,stories,actual_time_minutes,created_at,completed,completed_at,modified_at,start_on,sections,memberships,custom_fields,,parent'

But still ‘actual_time_minutes’ field is not included in the response.

opt_expand has been deprecated and really shouldn’t be used. Have you tried it with opt_fields as @John_Vu showed in his post?


How are people determining which tasks to pull entries from? If I want to find all time for a given month, for example, it seems I have to query all tasks with any time on them, then individually pull the entries, filtering out the ones that are not in the window I’m looking at. Am i missing an easier way?

Thank you, it worked.

For those curious, here’s how I pull time for the prior month. It’s ugly, and not fully battle tested, but it works for now.

  1. Get a list of all active projects in the workspace
  2. Loop through the projects and use the /tasks (get multiple tasks) endpoint to get all the tasks updated in the last month (this assumes adding time is considered updating a task, something I need to validate)
  3. filter those tasks to those which actually have time on them
  4. Loop through the resulting list of tasks and query the time entries for those
  5. filter out the time entries that aren’t in the last month

This has an added constraint that if a project is archived we can no longer pull time so we have a human-driven policy not to archive a project until 45 days (to be safe) after the project closed (and the last time entry posted).

Anyone know of a more efficient way?

If not, I would ask the powers that be at Asana to PLEASE add an endpoint where we could pull or search all time entries for a given workspace directly. It will significantly reduce load as more people have the same requirement that I do.

1 Like

Step 2 could be replaced with a call to the search endpoint. Potentially targeting the entire workspace could allow you to get rid of step 1.

You might be able to also put step 3 within the search criteria but I am not sure.

If you ask for the right fields using opt_fields in the search, you might be able to get rid of step 4 as well…

@Phil_Seeman what do you think?

I agree with @Bastien_Siebman, I think you could potentially save some steps with the Search API as he is suggesting.

Have you found a solution to this? I would like to do the same but with a different external timetracking tool (Hubstaff)

1 Like

I’ve used opt_fields instead of opt_expand but it doesn’t work as expected. We started to have missing fields which previously been in response when we used opt_expand.

What is the main difference between those two? And what I should do to get the same thing which I’ve got while using opt_expand.


To get fields within object properties, use dot notation. So for example:,