Follow these instructions before you pull massive data into any 3rd party apps, such as eazyBI or PowerBI, either from Cloud to Cloud or Cloud to Data Center.
📘 Instructions
Currently, the Tempo API gateway has a rate limit of 5 requests per second per IP address, regardless of the connection types: Application access, user token, or OAuth2 connection. The largest dataset stored in Tempo is from worklogs. The number of results returned is based on your REST call parameters, so try to avoid getting months of worklogs in one single call. Instead, it's recommended to write a script to loop through user/work item/week with pagination for better network traffic and server performance. You can narrow down your query with the following parameters:
-
Use a shorter time frame, such as by day or by week (instead of by month)
-
Use a single user (instead of teams)
-
Use pagination
-
Use a limit (default: 50, maximum: 5000)
Please follow closely the guidelines in both https://developer.atlassian.com/cloud/jira/platform/rest/v2/intro/ and Tempo https://apidocs.tempo.io/.
Do’s and Don’ts:
-
Test out your script to make sure there are no errors.
-
Monitor your usage for timeouts (1 second or more) and retries (maximum 3 times).
-
Have no more than 5 requests per second
-
Max 3 batches of 5r/s running in parallel (5r/s * 3 = 15r/s) by memory zone of 10mb
-
Wait at least 1000ms between each request.
API error codes and retry recommendation
|
ERROR CODE |
MEANING |
RECOMMENDATION |
|---|---|---|
|
4xx |
Client side error |
Do not retry; you need to fix the problem in the code |
|
429 |
Too many requests |
Retry after at least 1 second; avoid bursts of requests |
|
5xx |
Error on server side |
Retry 3 times with 5-, 10-, and 15-second pauses between retries |
If you fail to follow these recommendations and cause traffic overload on the Tempo API server, Tempo will take the drastic measure of blocking your IP from accessing the API server. In this case, please contact Tempo Support for further assistance.
Authentication: personal API tokens and OAuth tokens
A personal API token acts as the user who created it. An OAuth access token acts as the user who authorized the app, and each authorizing user receives their own token.
Symptom: A call returns 403 "User does not have permission" with an OAuth token, but the same call works with a personal API token.
Cause: The permissions checked are those of the user who authorized the OAuth app. That user may lack the permission the endpoint needs, for example Approve Timesheets for a team when calling the timesheet approvals endpoint.
Resolution: Grant the authorizing user the required permission, or authorize the app with a user who already has it.