Note:: During the period from 12:34:30 to 12:35:10, requests from other users would still be accepted as usual. Subsequent API requests will be rejected with a 429 response, but requests will be accepted a minute later at 12:35:10. *This will be explained more in section 4.įor example: Say USER A starts sending API requests at 12:34:10 and reaches the limit at 12:34:30. The number of permitted requests will reset a minute later. If a specific user exceeds the limit*, a 429 Too Many Requests response will be returned. This limit is on a minute-by-minute and user-by-user basis. The Backlog API will reject requests from specific customers when they are overly-concentrated in a short period. However, these measures ultimately still affect other customers because it takes time to recover from these failures. Until now, we have taken measures such as contacting customers directly to adjust their transmission interval or invalidating individual API keys when especially urgent. There have been several instances where overly-frequent requests have resulted in instability in some of Backlog’s functionality.

Best-practices for using the Backlog API.

When using two or more software together with the Backlog API.

When using your own software with the Backlog API.New Backlog spaces created starting today will have the new limits already in place.Īlthough we only expect these limitations to be an issue for a small number of our current API users, we recommend that all customers who are using the Backlog API adjust their request transmission interval and implement new request resending processing.īelow, we will explain more about what to expect and what you, the customer, may need to do to comply. Existing Backlog spaces that exceed the new limits will have until July 2021 to comply with the new restrictions. To keep Backlog running smoothly, we will begin limiting the number of requests that users can send to the API server per minute.

Viber update got rid of backlog