Rate Limits

Each API client may send up to 300 requests per minute.

• The limit is counted per API client, across all of its keys.
• The window is rolling: requests from the last 60 seconds are counted.
• Every authenticated request counts, including requests that end in an error. Requests rejected during authentication (401, 403 api_client_disabled, 403 public_api_unavailable) are not counted.

#When the limit is exceeded

The API answers with 429 Too Many Requests and a Retry-After header:

HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
Retry-After: 60

{
  "type": "https://api.worklogx.com/problems/rate-limit",
  "title": "Too many requests",
  "status": 429,
  "code": "rate_limit_exceeded",
  "requestId": "b2c4e6f8-0a1b-4c3d-8e5f-7a9b1c3d5e7f"
}

Wait the number of seconds given in Retry-After before sending further requests. The API does not send other rate-limit headers.

#Current implementation

The counter is kept in memory by each API server instance. If WorkLogx runs several instances, requests may be distributed across them and the effective limit can be higher than 300 per minute. Do not rely on this: design your integration for 300 requests per minute per API client.

#Staying within the limit

• Use limit=100 for list requests.
• Use updatedAfter for incremental syncs instead of full exports.
• Spread batch jobs over time instead of sending bursts.