[New] Time Tracking Entries API - Additional fields available

English Forum Developers & API Changelog
1

Summary

Three new fields are now available on all API requests that return TimeTrackingEntry entities: approval_status, billable_status, and description. These fields provide additional context about time tracking entries to help you better understand their approval workflow state, billing implications, and user-provided details. They are currently read-only.

What’s new

The following fields are now included in TimeTrackingEntry responses:

Field Name Type Description
approval_status string Current approval status for this time tracking entry. Possible values: "DRAFT", "SUBMITTED", "APPROVED", "REJECTED"
billable_status string Indicates whether this time tracking entry is billable. Possible values: "billable", "nonBillable", "notApplicable"
description string User-provided description for this time tracking entry

Usage

These fields can be requested as optional fields using the opt_fields query parameter. They will be returned by default when fetching a single time tracking entry by gid.

  • GET /tasks/{task_gid}/time_tracking_entries
  • GET /time_tracking_entries/{time_tracking_entry_gid}

Example request

// GET /tasks/{task_gid}/time_tracking_entries?opt_fields=approval_status,billable_status,description
{
  "data": {
    "gid": "12345",
    "resource_type": "time_tracking_entry",
    "duration_minutes": 12,
    "entered_on": "2015-03-14",
    "approval_status": "DRAFT",
    "billable_status": "billable",
    "description": "plan next shopping steps",
    "attributable_to": {
      "gid": "12345",
      "resource_type": "project",
      "name": "Stuff to buy"
    },
    "created_by": {
      "gid": "12345",
      "resource_type": "user",
      "name": "Greg Sanchez"
    },
    "created_at": "2012-02-22T02:06:58.147Z"
  }
}

Timeline

This is available now!

For complete details on time tracking entries, visit the Asana API documentation.

3 Likes
2

Thanks for the update, @John_Baldo - the additional fields are definitely helpful!

One question regarding user attribution: at the moment, the API only exposes the created_by user for a time tracking entry. In practice, however, the person who logs the time and the person who creates the entry are not always the same (for example, when an approver or manager logs time on behalf of another user).

Is there currently a way to retrieve the user the time entry is logged for, in addition to the user who created it? If not, is exposing this information on the roadmap? Or am I overlooking an existing field that already provides this distinction?

3

@Uli.Kisslinger I think in practice, the most reliable (and logical) way to determine “who the time entry is for” is to use the task context (the task’s assignee). As you noted, the time entry creator can be a different person, but the work itself is still owned via the task.

1 Like
4

@Mikhail_Melikhov I somewhat disagree. The UI offers the capability for different users to create time entries on a single task. Clients will want to report on that - and its possible to report on that in an Asana project. Why shouldn’t it be possible to report on that via the API?

Also, it feels kind of inconsistent when you are able to add meta data (logger) to an object (time entry) via the UI but you are not able to retrieve that meta data when fetching the same object via the API.

Using the task assignee and ignoring the loggers would only be a temporary workaround for me.

1 Like
5

@Uli.Kisslinger sorry, I don’t think I fully understood which reporting piece is missing (likely because I don’t work with time reporting day to day).

My understanding is that the entry “logger” is API-exposed via the created_by field on the time tracking object, while the task relationship provides the work/ownership context. Could you share an example of where this falls short in your setup? Happy to take that back internally.

6

@Mikhail_Melikhov I am happy to share an example:

In the Asana UI, it’s possible to create a time entry on behalf of another user (assumed you are the time approver for that user). In the screenshot below, I created a time entry for my colleague:

image
image1946×802 72.7 KB

However, when I fetch the time entries for this task via the API, the response only includes the created_by field and not the user the entry was actually logged for (the “logger” shown in the UI).

{
    "data": [
        {
            "gid": "XXXX",
            "resource_type": "time_tracking_entry",
            "duration_minutes": 60,
            "created_by": {
                "gid": "XXXX",
                "name": "Uli Kisslinger",
                "resource_type": "user"
            },
            "attributable_to": {
                "gid": "XXXX",
                "name": "Time Tracking Test",
                "resource_type": "project"
            },
            "entered_on": "2026-01-20"
        },
        {
            "gid": "XXXX",
            "resource_type": "time_tracking_entry",
            "duration_minutes": 60,
            "created_by": {
                "gid": "XXXX",
                "name": "Uli Kisslinger",
                "resource_type": "user"
            },
            "attributable_to": {
                "gid": "XXXX",
                "name": "Time Tracking Test",
                "resource_type": "project"
            },
            "entered_on": "2026-01-20"
        }
    ]
}

As a result, the API output (which would be the foundation for custom reporting) makes it look like both entries belong to me, simply because I created them. In reality, the tracked time should be attributed to my colleague, since I logged the time on their behalf.

A real-life example:

A colleague submits their timesheet and I review it. I notice that 2 hours were tracked as billable on a client project. I decide that only 50% should be billed, so I update the existing entry to 1 hour (non-billable) and then add a second entry for 1 hour (billable) - both attributed to my colleague.

With the current API response, one entry would be attributed to me via created_by, which makes it impossible to generate accurate user-based reports from the API.

So my question is: shouldn`t there be a way to retrieve the logger and the user who created the time entry via the API, as both can be different users?

2 Likes