Rate limits and known limitations

Overview

This page collects the limits and practical constraints to plan a REST API integration around.

Rate limits

TimeLog has not published rate limits for the REST API. Usage is monitored, and TimeLog contacts the employee marked as TimeLog Responsible in the account before limiting its API use. See Usage and change policy.

There are no published request quotas, burst limits or rate-limit response headers to design against. Until there are, general HTTP practice keeps an integration well-behaved:

• Back off if you receive 429 or 503. Wait before retrying, and increase the wait on each repeated failure. Do not retry in a tight loop.
• Avoid tight polling. Read on a schedule that matches how fresh your data needs to be, not as fast as the API answers.
• Retry writes only when they are safe to repeat. A retry after a timeout can create a duplicate. See Errors — When to retry and Writing data — Safe retries.

Environments and sandbox

To ask about a test environment for your integration, contact TimeLog through timelog.com/en/contact.

Network requirements

For questions about network requirements, such as IP allowlisting, contact TimeLog through timelog.com/en/contact.

Coverage of the reference

The API reference — v1 and API reference — v2 groups in the sidebar cover 338 operations: 226 in v1 and 112 in v2.

• Not every operation is included yet. A small number of operations in TimeLog's API description are not yet included in this reference while their documentation is completed.
• Response examples are shown only where a verified response was available. An operation without an example still documents its response model.
• Some descriptions are shorter than others on purpose. Details that could not be verified were left out rather than guessed.

Report a documentation problem

To report a documentation problem or ask a question about the REST API, contact TimeLog through timelog.com/en/contact.