The API is work-in-progress. Follow this topic to get notified about new endpoints, and changes (if it would be required - we try not to change existing endpoints if we don’t have to).
The API docs started to get quite extensive, so we moved it to
http://devcenter.bitrise.io/api/v0.1/ for easier digest and for better Table of Content and link-to-section support. WIP / working on it
Download build log
Get build artifacts + download URLs (
Abort a build endpoint (with reason + status param); should be possible to abort a build with success status
Manage (upload & download) files located under “Code Signing & Files” on
limit query param & errors
/builds list - filter:
branch - together with
limit=1 this can be used for quickly checking the status of the latest build & the latest on a specified branch
Enforce HTTPS for the API - redirect from http to https
Build Trigger endpoint
bitrise.yml of a project
Watch / Unwatch an app (notifications)
Feature / endpoint requests
If you want to request a new API feature / endpoint, please do it here:
I'd very much like an API for bitrise. For configuring applications etc.
For example, upload/read workflow, update/read stack, read build list, etc.
I guess there isnt something like this, because I havent found it. Is something like this planned?
Have you thought about publishing a swagger description of the API so that it’s easy to generate SDKs?
At one point we definitely will, but no ETA for that yet.
FYI there is some inconsistency with the error handling.
“message”: “Not Found”
“error_message”: “Not Found”
Good catch, thanks for reporting!
(I’ll let you know here when it’s fixed)
Is is possible to make
https://api.bitrise.io/v0.1 respond the same as https://api.bitrise.io/v0.1/? The API modeling software I’m using appends a trailing slash which results in
Ideas for improving the returned data:
Identify cancelled builds (requires having an end point to cancel builds)
Text status of the build result (failed, succeeded, cancelled, etc.)
Trailing slash: fix scheduled
Endpoint improvements: exactly what I had on my list, so it shouldn’t take too long
DONE: Pagination docs section added
DONE: Include this discuss URL in the “link to docs” message in the root response of http://api.bitrise.io/
DONE: FIX: “Content-Type” instead of “Content Type” (missing -)
Content-Type is now set to
application/json; charset=utf-8 for every endpoint.
DONE: Handle /x and /x/ the same way (trailing /) - Bitrise.io API v0.1 (Work In Progress)
/v0.1/ is a redirect to
DONE: FIX: error message response format inconsistency - Bitrise.io API v0.1 (Work In Progress)
Fixed, every endpoint should now return with
message in case of error (and a proper HTTP code, of course), instead of with
Thanks for reporting
DONE: Build: status: return a
status_text too, not just the code, as well as
DONE: Include commit hash & message in build data
A post was merged into an existing topic:
Bitrise Public API
DONE: Include build time, and build start & finish times in the build data.
Included times in the response:
Thank you for adding the build time info. That’s super helpful for measuring build health.
Indeed, we have quite a few use cases for these data as well
Will push another update shortly, with “abort reason” included if the build was aborted, as well as normalizing empty infos to be
null instead of empty strings (e.g. if a
tag is not defined it’ll be
"tag":null instead of
DONE: Build: Abort reason (if any)
CHANGE: undefined parameters are now returned as
null, instead of a default value (e.g. an empty string). Change example: previous
tag was not specified for the build.