Bitrise.io API v0.1 (Work In Progress)

Development Beta Testing
1

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 (/download endpoint?)
  • 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 bitrise.io
  • Docs: 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
  • Download/upload/edit the 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:

9 Likes
3

Have you thought about publishing a swagger description of the API so that it’s easy to generate SDKs?

2 Likes
4

At one point we definitely will, but no ETA for that yet.

1 Like
5

FYI there is some inconsistency with the error handling.

https://api.bitrise.io/v0.1/me/
{
“message”: “Not Found”
}

vs

/apps/123/builds
{
“error_message”: “Not Found”
}

1 Like
6

Good catch, thanks for reporting! :wink:

(I’ll let you know here when it’s fixed)

1 Like
7

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 Not Found.

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.)
  • Build times
2 Likes
8

Trailing slash: fix scheduled :wink:

Endpoint improvements: exactly what I had on my list, so it shouldn’t take too long :slight_smile:

9

DONE: Pagination docs section added

1 Like
10

DONE: Include this discuss URL in the “link to docs” message in the root response of http://api.bitrise.io/

1 Like
11

DONE: FIX: “Content-Type” instead of “Content Type” (missing -)

Content-Type is now set to application/json; charset=utf-8 for every endpoint.

1 Like
12

DONE: Handle /x and /x/ the same way (trailing /) - Bitrise.io API v0.1 (Work In Progress)

Tech Note: /x/ redirects to /x; e.g. /v0.1/ is a redirect to /v0.1

1 Like
13

DONE: FIX: error message response format inconsistency - Bitrise.io API v0.1 (Work In Progress) - #5 by bootstraponline

Fixed, every endpoint should now return with message in case of error (and a proper HTTP code, of course), instead of with error_message.

Thanks for reporting @bootstraponline! :wink:

1 Like
14

DONE: Build: status: return a status_text too, not just the code, as well as is_on_hold

1 Like
15

DONE: Include commit hash & message in build data

16

A post was merged into an existing topic: Bitrise Public API

17

DONE:

  • Include tag in build data (tag)
  • Include workflow id in build data (triggered_workflow)
1 Like
18

DONE: Include build time, and build start & finish times in the build data.

Included times in the response:

  • triggered_at
  • started_on_worker_at
  • environment_prepare_finished_at
  • finished_at
1 Like
19

Thank you for adding the build time info. That’s super helpful for measuring build health. :slight_smile:

1 Like
20

Indeed, we have quite a few use cases for these data as well :wink:

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 "tag":"")

2 Likes
21

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":"" is now "tag":null when tag was not specified for the build.