This page provides details about rate limiting for app migration, and can help you understand how to anticipate rate limiting and manage how your app responds.
As with all web requests, you may receive HTTP responses for requests made to app migration platform from the cloud app.
While calling the app migration platform methods from your server app, if the rate limit is exceeded you will receive with an exception message . You will get this new exception message, for following versions of Cloud migration assistant.
Apps should treat 429 responses as a signal to alleviate pressure on an endpoint and retry the request only after a delay. The best practice is to double the delay after each successive 429 response from a given endpoint. Backoff delays only need to exponentially increase to a maximum value at which point the retries can continue with the fixed maximum delay. You should also apply jitter to the delays to avoid the thundering herd problem.
The following articles provide useful insights and techniques related to retry and backoff processing:
There are currently no rate limits specific to app migration in Jira.
In order to ensure your app migration code does not impact any other Confluence customer on the same infrastructure, you must provide each request to any Confluence REST API with the HTTP header . You can use any value with this header.
See an example
Use this header to ensure that your migration path does not impact customers, and avoids the possibility that your app key can be banned from app migration.
The table below details the current rate limits in Confluence.
|per app per Confluence cloud instance
|per Confluence cloud instance
As with all web requests, you may receive HTTP responses.
We do not expect more than two concurrent Confluence apps to make calls to our APIs during a migration. However, in order to prepare for the possibility that this may happen, all apps need to implement the retry policy of rate limiting responses.
Rate this page: