Asynchronous provisioning allows add-ons to perform out-of-band provisioning in a first-class way. It’s intended for add-on services that need extended time to set up and help make automated app setup and orchestration easier and less error-prone.
The customer will be billed as soon as the add-on starts provisioning. This means the time and cost of provisioning your service is accounted for in how much a customer pays. As such, you should make every effort to provision expediently so customers get value from your service as quickly as possible.
Add-ons that take longer than 12 hours to provision (or those your service fails to mark as “provisioned” via the API in that time period) will be considered failed and removed from the user’s app. The customer will not be charged in this case and no money will be passed on to the Partner.
Previously, we needed to manually flag partners into async provisioning. Going forward, all add-on services will flagged into async provisioning by default. With this change, we will stop supporting 202 HTTP status responses for add-ons that do not support async workflow.
In lieu of 202 responses, an update to 200 HTTP status responses are required if your add-on integration isn’t set up for async provisioning. If your add-on continues to respond with 202 and does not support async provisioning, all add-on provisions will be deleted after the timeout is exceeded.
Check out the Asynchronous Provisioning of Add-ons documentation for more details on how to implement async workflow for your add-on.