Dashboard widgets and reportsGet my time-registration accuracy for a period

Get my time-registration accuracy for a period

Returns how many days, on average, the caller registered project time after the work date — for a period and for the equally long period before it.

Computes, for the CALLER only, the average delay in days between a project time registration's work date and its creation day, over registrations whose work date lies in [startDate, endDate] (AccuracyCurrentPeriod) and in the equally long period immediately before startDate (AccuracyPreviousPeriod), plus the timestamp of the caller's latest change to a project registration (LastRegistrationDate). Full formula, rounding, exclusions and the previous-period arithmetic are on WidgetDataTimeRegistrationAccuracyRead. Both dates are reduced to calendar days (time part dropped); no timezone conversion. There is no validation that startDate ≤ endDate: with startDate after endDate no registration matches and both values are 0.

Use it to:

  • Show a user how promptly they register time, and the trend against the previous period

Not for:

  • Another employee's or a team's registration delay — the route always computes the caller's own

Rules across fields:

  • startDate ≤ endDate is expected but not checked; a reversed range returns 0 for both periods.

Behaviour:

  • Idempotent.
  • Safe to retry.
  • Changes are visible to the next read immediately.

See also: GET /v2/widget-data/external-percentage, GET /v2/widget-data/billable-percentage

Not yet documented: errors; examples.

curl -X GET "https://app3.timelog.com/your-account/api/v2/widget-data/time-registration-accuracy?startDate=2024-12-25T10%3A00%3A00Z&endDate=2024-12-25T10%3A00%3A00Z" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_TOKEN"
{
  "Properties": {
    "UserId": 123,
    "StartDate": "2024-12-25T10:00:00Z",
    "EndDate": "2024-12-25T10:00:00Z",
    "LastRegistrationDate": "null",
    "AccuracyCurrentPeriod": 3.14,
    "AccuracyPreviousPeriod": 3.14
  },
  "Links": [
    {
      "Href": "example_string",
      "Rel": "example_string"
    }
  ],
  "Actions": [
    {}
  ]
}
GET
/v2/widget-data/time-registration-accuracy
GET
Base URLstring

Target server for requests. Edit to use your own host.

Bearer Token
Bearer Tokenstring
Required

OAuth 2.0 bearer token, sent as Authorization: Bearer <token>. JWT and reference tokens are both accepted. The token must carry the required scope (default tlp). The token's sub claim is the acting user. A token WITHOUT sub (client-credentials) acts as the system service user. If the sub user cannot log in (inactive, locked, deleted), the request is rejected with 401 — it is no longer let through without a user. > Not yet documented: how to obtain a token. > Not yet documented: token lifetime.

OAuth 2.0 bearer token, sent as Authorization: Bearer <token>. JWT and reference tokens are both accepted. The token must carry the required scope (default tlp). The token's sub claim is the acting user. A token WITHOUT sub (client-credentials) acts as the system service user. If the sub user cannot log in (inactive, locked, deleted), the request is rejected with 401 — it is no longer let through without a user. > Not yet documented: how to obtain a token. > Not yet documented: token lifetime.
query
startDatestring
Required

First day of the period (inclusive). Any time part is dropped. Omitted → 404 action not matched (captured). Filters on time registration work date (gte). Date only — no time component.

Format: date-time
query
endDatestring
Required

Last day of the period (inclusive). Any time part is dropped. Omitted → 404 action not matched. Filters on time registration work date (lte). Date only — no time component.

Format: date-time
Request Preview
Response

Response will appear here after sending the request

Authentication

header
Authorizationstring
Required

Bearer token. OAuth 2.0 bearer token, sent as Authorization: Bearer <token>. JWT and reference tokens are both accepted. The token must carry the required scope (default tlp).

The token's sub claim is the acting user. A token WITHOUT sub (client-credentials) acts as the system service user. If the sub user cannot log in (inactive, locked, deleted), the request is rejected with 401 — it is no longer let through without a user.

Not yet documented: how to obtain a token.

Not yet documented: token lifetime.

Query Parameters

startDatestring
Required

First day of the period (inclusive). Any time part is dropped. Omitted → 404 action not matched (captured).

Filters on time registration work date (gte).

Date only — no time component.

endDatestring
Required

Last day of the period (inclusive). Any time part is dropped. Omitted → 404 action not matched.

Filters on time registration work date (lte).

Date only — no time component.

Responses

Propertiesobject

"Time registration accuracy" of ONE user (the caller): on average, how many days after the work date the user's project time registrations were created, for a period and for the equally long period just before it. 0 = registered on the day (or no registrations); higher = registered later. Only project time counts (registrations of EntityType 43 = Allocation, i.e. on a task allocation); absence is excluded.

Linksarray
Actionsobject[]