Add Release Management API how-to guides - #53
Conversation
Moves the existing RM API overview into a new api/ subfolder and adds five step-by-step API guides covering app connection, releases, presets, build distribution, and store release flows for iOS and Android. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Rename "release" to "app version" for the individual resource, matching product terminology; group category naming under "Create store releases" to match the product's Releases section - Restructure the overview feature list into one item per category - Replace the incomplete automation event list with the full iOS/Android event lists from the release-automation page - Remove the unused release timeline section - Fix a broken self-referential link in the overview page Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Mirrors the existing Bitrise CI / RDE setup: commits a snapshot of each of the four Release Management sub-API specs (Apps, Store Releases, CodePush, Build Distributions), generates their reference docs via docusaurus-plugin-openapi-docs, and wires them into the Release Management sidebar as a nested "API reference" category alongside the hand-written "API guides". - Add per-sub-API sync scripts and nightly workflow entries, matching the RDE pattern, so the snapshots stay current automatically - Normalize generated operation titles (strip trailing periods, un-conjugate third-person-singular leading verbs) as a permanent post-generation step, which also fixes the same pre-existing issue in the Bitrise CI reference - Rename the "Release Management API" sidebar label to "API guides" to distinguish the how-to guides from the new generated reference Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Addresses the review's request for Swagger links, now pointing at the newly generated internal API reference instead of the external Swagger UI: - Add a reference link next to every sub-API base URL mention - Link every endpoint-table row to its exact operation page, verified against the real OpenAPI spec paths Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
| Use the presigned URL from the previous response to upload the file directly to storage: | ||
|
|
||
| ```bash | ||
| curl -X PUT "PRESIGNED_UPLOAD_URL" \ | ||
| -H "Content-Type: application/octet-stream" \ | ||
| --data-binary "@/path/to/MyApp.ipa" | ||
| ``` |
There was a problem hiding this comment.
Content-Type header's value is wrong, and one other header is missing. I would also mention what kind of files you can upload ipa/apk/aab
#Use the method, url, and headers exactly as returned by the Step 1 response.
curl -X PUT "PRESIGNED_UPLOAD_URL" \
-H "Content-Type: <value from response headers>" \
-H "X-Goog-Content-Length-Range: <value from response headers>" \
--data-binary "@/path/to/MyApp.aab"
|
|
||
| The response returns the current `status`. Poll this endpoint until the status indicates the artifact is ready for distribution. | ||
|
|
||
| ## Enabling a public install page |
There was a problem hiding this comment.
The list endpoint would be usefule before or after this section to let the user know how they can obtain the ARTIFACT_ID. And unfortunately the list endpoint returns artifact that has both id and uuid fields, here the uuid has to be used.
There was a problem hiding this comment.
List endpoint:
curl -X 'GET'
'https://api.bitrise.io/release-management/v2/apps/v1/installable-artifacts?app_id=b84fec4d-0139-489a-ae7c-8dea5474c64c&items_per_page=10&page=1&store_signed=false'
-H 'accept: application/json'
| import Tabs from '@theme/Tabs'; | ||
| import TabItem from '@theme/TabItem'; | ||
|
|
||
| You can upload build artifacts to Release Management and distribute them to internal tester groups directly via the API. This covers both the artifact upload flow (Apps sub-API) and tester group management (Build Distributions sub-API). |
There was a problem hiding this comment.
We already have external tester groups and it's not mentioned in the docs
|
|
||
| ### Creating a tester group | ||
|
|
||
| ```bash |
There was a problem hiding this comment.
You can create either internal or external tester groups with this endpoint, I would definitely mention that, and I would change the url to make it clear how (see the attached image, at the end of the url there is a type option with possible values external/internal)
| ### Adding testers to a group | ||
|
|
||
| ```bash | ||
| curl -X POST "https://api.bitrise.io/release-management/v2/build-distributions/v1/tester-groups/GROUP_ID/add-testers" \ |
There was a problem hiding this comment.
Here you can also provide the ?type=external/internal at the end of the url and when the type is external there are no user_slugs but emails in the body:
curl -X 'POST' \
'https://api.bitrise.io/release-management/v2/build-distributions/v1/tester-groups/0af00fd7-7746-4b00-9d29-728a9bc06610/add-testers?type=external' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-d '{
"emails": [
"tester@example.com"
]
}'
So it might be worth to show two examples for external and internal
| import Tabs from '@theme/Tabs'; | ||
| import TabItem from '@theme/TabItem'; | ||
|
|
||
| Once your release has a release candidate and all approvals are completed, you can submit the app for store review and then release it to users. |
There was a problem hiding this comment.
Maybe we should highlight that the store review is only present for ios, and you also need to upload first to the store both for ios and android so:
Once your release has a release candidate uploaded to the store and all approvals completed...
2 participants
Summary
Test plan
/en/release-management/api/🤖 Generated with Claude Code