How to Edit Tracked Time in ClickUp Using the API

What the ClickUp edit time tracked endpoint does

ClickUp provides an endpoint for updating an existing tracked-time record:

PUT /api/v2/team/{team_id}/time_entries/{time_entry_id}

The team_id identifies the ClickUp workspace, while the time_entry_id identifies the specific time record to change. The request can update the duration and, where supported by the account and endpoint, related metadata such as start and end timestamps, billable status, description, tags, task association and assignee.

The endpoint should be used when the business meaning of the original time entry is still valid but one or more values are incorrect. If the record represents a completely different piece of work, changing it in place may damage reporting history. In that situation, a separate correction process may be more appropriate.

Fields to identify before sending the request

A successful update depends on more than an API token. Gather the identifiers and intended values before constructing the request.

• team_id: The ClickUp workspace ID in the endpoint path.
• time_entry_id: The ID of the existing tracked-time record.
• duration: The updated total duration in milliseconds.
• start and end: Unix timestamps in milliseconds when the time window must be corrected.
• billable: A boolean indicating whether the time should be treated as billable.
• description: The explanatory note for the work performed.
• tag_ids: The tags that should be associated with the entry.
• tid: The task ID when the entry needs to be associated with a different task.
• assignee: The user ID for the person whose time is represented.

The duration is the key field for this operation. Treat it as a complete replacement value, not as an increment. If the intended result is 45 minutes, send the total millisecond value for 45 minutes rather than sending the number of milliseconds to add to the current entry.

Authentication and request structure

Send the request to the ClickUp API base URL with the workspace and time-entry identifiers inserted into the path:

https://api.clickup.com/api/v2/team/{team_id}/time_entries/{time_entry_id}

The request should include an authorization header containing the ClickUp API token and a JSON content type header. The body should contain the updated duration and any other fields that the endpoint accepts for the intended change.

A conceptual update body could include a duration of 3,600,000 milliseconds for one hour, a corrected start and end time, a billable value, a description, a task ID, an assignee ID and a list of tag IDs. Use real identifiers from the target workspace rather than placeholder values, and confirm the current ClickUp API reference before relying on a field that is not central to the correction.

When building an integration, keep the request construction separate from the business rule that decides whether an edit is allowed. This makes it easier to test the conversion and payload without accidentally giving every user or automation permission to rewrite historical time.

A practical sequence for editing a ClickUp time entry

This sequence separates identification, decision-making and execution. That separation matters when time entries are changed by a synchronization job, an approval process or a correction form rather than by a developer running a one-off request.

Duration and timestamp validation

ClickUp represents duration in milliseconds. Common conversions include 30 minutes as 1,800,000 milliseconds and one hour as 3,600,000 milliseconds. A conversion function should receive a clearly defined unit and reject empty, negative or implausibly large values before the API call is made.

When start and end values are supplied, check that the end timestamp follows the start timestamp and that the calculated interval agrees with the duration being sent. If the values disagree, decide which one is authoritative. Do not allow an integration to silently send conflicting time information.

For example, suppose an employee records two hours against a task but the correct value is 90 minutes. The correction workflow should identify the original entry, convert 90 minutes to 5,400,000 milliseconds, preserve the original two-hour value, send the update and verify that the stored duration is now 5,400,000 milliseconds. It should not simply subtract 30 minutes without checking the source units and entry identity.

Editing billable status, task details and metadata

Not every correction requires a new duration. A finance review may change a time entry from billable to non-billable. A synchronization process may normalize a description or replace tags. A project administrator may need to correct the task association or assignee.

These changes should still be handled as controlled updates. A billable flag can affect invoicing or internal reporting, so it should have a visible owner and a reason for change. A task reassignment can alter project totals, which means the workflow should verify that the destination task belongs to the expected workspace and project.

Responses, errors and operational checks

After the PUT request, inspect the response rather than assuming that a successful network call means the data is correct. Confirm the returned time entry ID and compare the saved duration, timestamps, billable state and associations with the intended values.

Common failure causes include an incorrect workspace ID, an invalid time-entry ID, an absent or malformed duration, a conversion error, insufficient permissions or a payload that does not match the current endpoint contract. Error handling should record the response status and enough context to investigate without exposing the API token.

For recurring integrations, make the update process observable. Record when the correction was requested, which system initiated it, who or what approved it, which fields changed and whether the final verification succeeded. This creates a useful operational trail without requiring the ClickUp record itself to hold every piece of audit information.

Designing a reliable correction workflow

A useful design rule is to make the reason for the edit explicit. Examples include correcting a time import, approving a submitted adjustment, fixing a task mapping or changing a billable classification. Each reason can have different validation and ownership requirements.

Consider a hypothetical integration that imports time from an external system into ClickUp. If the source later corrects a duration, the integration should match the original entry using a stable external reference or a carefully verified ClickUp ID. It should not search by description alone because similar descriptions can belong to different tasks or users.

For a small number of manual corrections, a controlled form can collect the time-entry ID, proposed values and reason. For larger volumes, a queue can separate approved changes from failed API requests. In both cases, automation should execute a clear decision rather than decide what constitutes an acceptable correction.

ClickUp can be part of a wider operating system, so time-entry changes may affect project reporting, finance, payroll or customer billing. If those downstream systems depend on the data, define when they should be notified and whether a correction requires a report refresh or reconciliation step.

For broader workspace design, see ClickUp consulting for workspace architecture and workflows. If the time data must connect with other business systems, Zapier automation and integrations may be relevant when the required logic fits that approach. ConsultEvo’s ConsultEvoInternational Talent Recruitment and ClickUp Hiring WorkflowAn example of ClickUp workflow design supporting a broader operational process.→

Key principles for editing ClickUp time safely

An API endpoint can perform the edit, but it cannot determine whether the edit is operationally correct. That requires an explicit process, clear ownership and validation against the systems that consume the time data.

• Use the existing time-entry ID only when the record still represents the correct work.
• Treat duration as a complete millisecond value and validate it before transmission.
• Keep billable changes and reassignment changes visible to the responsible owner.
• Preserve the original state when billing, payroll or reporting depends on the history.
• Verify the saved response instead of treating request completion as proof of correctness.

More tools do not automatically create better time tracking. A dependable workflow comes from clear business rules first, then a carefully scoped API call, then verification and reporting that support an actual decision.