API v0.1 (Work In Progress)



One issue I’m running into when calculating build metrics. There’s no way to differentiate cancelled builds from successful builds.

I have a large mono repo on GitHub. Git changes are used to determine if the build should run or not. From the Bitrise perspective, it looks like the build completed successfully. However in reality we didn’t run the build because no changes were detected.

An API to mark the build status as cancelled would be awesome.


I see your point, but not sure how this would work. Would this be a completely separate “state” of the build? Something like “aborted”? Or would it be enough if you could simply “abort” the build through an API call right from the build, specifying an abort reason which you can now get in the /builds query?

If you have a proposed solution feel free to create a #feature-request !

  • Abort a build

is already listed here as an upcoming API so not sure a new feature request makes sense?

It’s helpful to look at how other providers handle this. On buddybuild, they created a new endpoint for canceling a build. Canceling a build is not the same as aborting. It’s a new state of the build. This is important to filter out manual aborts via the web UI from the automatic cancellation logic that ensures we’re only building changed code in a mono repo. There’s also a hidden parameter on this endpoint which controls how the GitHub status check is reported. A cancel can be reported as either a success or failure based on the value of this parameter that’s passed to the cancel endpoint.

The way this works in a mono repo workflow is as follows:

  • New PR comes in. A bunch of jobs are triggered. Custom git logic determines which apps have changed code. If there are no code changes in an app, then the build is marked as “cancelled” and filtered out of the build metrics reporting dashboard.

On bitrise we have something similar however there’s no API to cancel builds. Instead the builds run and exit early which is considered a “successful” build. However this pollutes the build metrics reporting because successful builds that executed to completion are mixed with successful builds that exited early due to change detection.


My question was exactly whether an /abort endpoint would be enough. That is definitely planned.

Having a separate /cancel endpoint, regardless how “other providers handle this”… I’m not convinced. Or maybe it’s the same thing just with different words.

In our case we call any build which “finished early” an aborted build. Marked differently on the UI as successful or failed ones. In the API you can filter these out as these have an “aborted” status. And an API endpoint to abort a build is coming soon.

I can’t see a meaningful difference between aborting and canceling a build if done through the API, but if you have a use case where aborted vs canceled builds might be a useful distinction just let me know!

Edit: note, in our case you can specify an “abort reason” which is included in the API response of build data, so you can have as many special “abort types” as you like. I don’t think having multiple endpoints for “finishing builds early” is a good idea, because you’d slowly end up with more and more endpoints for the exact same thing, to finish a build early.


Having a separate /cancel endpoint … I’m not convinced

I agree, I’m not asking for both /cancel and /abort. We need one though, regardless of what it’s called. There are different use cases for why builds are aborted, lumping them all together isn’t helpful.

I can’t see a meaningful difference between aborting and canceling a build if done through the API,

These builds shouldn’t even be making it to bitrise. When there are no code changes, a build should not be triggered in the first place. The hack of doing git change detection is just a work around for lack of first class mono repo suppport.

if you have a use case where aborted vs canceled builds might be a useful distinction just let me know!

If we are cancelling a build because there are no code changes vs aborting a build manually on the UI, that’s important info to have.

I don’t think having multiple endpoints for “finishing builds early” is a good idea,

I’m not asking for multiple endpoints. Sorry that wasn’t clear. I’m asking for a differentation between build states. Using a magic string in “abort reason” seems like it’d work but isn’t ideal.


Makes sense. Not sure what a better solution would be, I mean with a string which you can specify you can have as many “states” or “types” as you like, which is more flexible than just a couple of special build status codes.

I’d say you could use this “reason” as “tags” or “type”, the point will be that it’s up to you how you use it. But if you have a better idea we’re definitely open :wink:


FYI it looks like that other provider just considers everything as “cancelled” so if having a distinction here is an issue then that’s fine.

The real value is being able to mark these as aborted & green on a GitHub status check without mislabeling them as a successful build. This is not currently possible.


Can you please clarify this a bit in a #feature-request? Would love to hear more, to see how we could help.


Bumped the priority of the /abort endpoint in the meantime.


Hi, a quick question about the commit_message field in builds data. Shouldn’t this be build_message (or simply message), since the value that is returned here is the one we can provide when starting a build. If so, is there a chance to include the actual commit message? Or am I missing something?


@PawelLopusinski good question. If the build was started by a git event this will be the commit message.

That’s not possible right now, these infos are the ones the build was started with, and are not updated during the build. If you’d want to see that please create a #feature-request


No, it’s fine. I never used git triggers to start builds on BitRise, so that’s why the whole thing looked a little confusing for me. On the other hand - info as to what triggered the build (i.e. manually/git event/schedule/other) could be added. Then the commit_message field would get a little more context it seems.


Definitely, that’s on our list, should be available in the next couple of weeks :wink:


DONE: Return status and info of a single build; for checking the build’s status after triggering it, during the build (check when it’s finished)

Bitrise Public API

Is there any ETA when trigger a build endpoint will be released? I have a chatbot which can trigger builds, but since each app needs its own api key, maintaining keys for 10+ repos seems to be a nightmare.


No ETA, for now triggering builds should happen through the existing Build Trigger API (


is it possible to use the personal access token to trigger builds instead of the app api key?


Not yet, that’s pretty much what this point in the WIP section will cover:


The API docs started to get quite extensive, so we moved it to for easier digest and for better Table of Content and link-to-section support.


API docs are now auto-generated ( - using an “api-demo” bitrise user prepared solely for the purpose of generating these docs); this should speed up the publishing of those docs, and help to keep them up to date :wink:

New endpoints are coming “real soon” :slight_smile: