Staged Rollout Release

The following is an example of the sequence of Content Publish APIs used to submit a release with a staged rollout. This is one of many ways a staged rollout can be set up. Depending on your requirements, you may require different or additional API calls.

1. POST /seller/createUploadSessionId

   Create a session ID to upload the new binary.

   
   

2. POST /galaxyapi/fileUpload

   Upload the new binary and get a file key.

   
   

3. GET /seller/contentInfo?contentId=XXXXXXXXXXXX

   Get the app information of the binary that is for sale (the appStatus is SALE). The information in the response can be modified in the next step.

   NoteIf you want to copy the device configuration (the devices a binary is targeting) from an existing binary to the new binary, save the binarySeq value from the existing binary from which you want to copy the device configuration. This value is used when you add a new binary (see step 7).

4. GET /seller/v2/content/stagedRolloutRate?contentId=XXXXXXXXXXXX&appStatus=SALE

   Check the current rollout rate for this content. If there is no staged rollout enabled for the app, skip to step 6.

   NoteTo enable a staged rollout for an upcoming update, the existing staged rollout must be disabled (that is, the app must be deployed to all users globally).

5. PUT /seller/v2/content/stagedRolloutRate
{"function": "DISABLE_ROLLOUT", "appStatus": "SALE", "contentID": "XXXXXXXXXXXX"}

   If there is an existing staged rollout for your app, you must disable the existing staged rollout before you can set a new one.

6. POST /seller/contentUpdate

   Create an update for the app (the appStatus of the update is REGISTRATION). After calling this API, the app has two appStatus statuses (SALE and REGISTRATION). See Status Parameters for more information about the appStatus parameter. You will add the binary for the update in the next step.

   During this step, you should make any required metatdata changes as well as any adjustments to the countries where the app is to be distributed.

   
   

7. POST /seller/v2/content/binary?contentID=XXXXXXXXXXXX&gms=Y/N&filekey=xxxxxxxxx&binarySeqForDeviceInfo=X

   Register the binary you uploaded in step 2 and copy the device configuration (if desired) from an existing binary based on the binarySeq value you noted in step 3.

   
   

8. PUT /seller/v2/content/stagedRolloutBinary
{"function": "ADD", "binarySeq": "binarySeq_of_the_binary_registered_in_step_7", "contentID": "XXXXXXXXXXXX"}

   Enable the staged rollout for the binary registered in step 7. If you don't know the binarySeq, use GET /seller/contentInfo to get it.

9. PUT /seller/v2/content/stagedRolloutRate
{"function": "ENABLE_ROLLOUT", "appStatus": "REGISTRATION", "contentID": "XXXXXXXXXXXX", "rolloutRate": XX}

   Set the desidred rollout rate for the initial staged rollout release.

10. POST /seller/contentSubmit

    Submit the app for review.
    

    NoteIf the publicationType of the app is set to manual publication, the app does not go live after it has passed the review. There will be an app pending release whose appStatus is REGISTRATION. This app must be released using POST /seller/contentStatusUpdate before the next update can be created (see step 11).

11. (Optional) POST /seller/contentStatusUpdate
{"contentId": "XXXXXXXXXXXX", "contentStatus" :"FOR_SALE"}

    Release the app. Required if a manual publication was selected to release the pending updated app.

12. (Optional) PUT /seller/v2/content/stagedRolloutRate
{"function": "ENABLE_ROLLOUT", "appStatus": "SALE", "contentID": "XXXXXXXXXXXX", "rolloutRate": XX}

    Update the staged rollout rate of the released app.

    NoteThe rollout rate must be greater than the previously used rollout rate.