Custom integrations with outgoing webhooks

We've updated how and what you can do with our outgoing webhooks so you'll be able to send your build events to whatever service you love and configure it easily.

You can now use the same notification system as we are, but with your own service. You can use this notification to share build statuses with your git provider if we don’t support it yet, notify only the right team about build success or failure, or use it to automate your in-house release pipeline. There are no limits! Let us know, how you use our webhooks!

Our past webhooks

So far, we used outgoing webhooks only to transfer information to GitHub, Bitbucket, and GitLab. If a PR was opened and the build started, Bitrise sent a message through a webhook to let's say GitHub to report the success of the build. This was set on server level, so if you wanted to implement something custom, you had to hack it with a script step, during build time.

Setup and configure webhooks on your app pages

From now on, you'll have the chance to setup and configure the webhooks sent by Bitrise in the UI, that is: open your app and check out the { } Code tab. 🙂

You can set what should trigger a webhook: the trigger can either be a build event, or you can set it to "all events", which means that in the future if there is another option, it'll get triggered not only by build events. (Yes, we're working ahead. 😉)

Build events are:

• if a build gets started
• if a build ends

You can see if the notifications were sent or not and if you click on a webhook, you'll see all the info about it (under Recent deliveries):

• the messages (payload) that were actually sent, along with the information whether it made it till the server. The event type that triggered the webhook will be sent in a custom header:

"Bitrise-Event-Type": "build/triggered" # or "build/finished"

Example payload:

{
  "build_slug":"1234abcd",
  "build_number":3,
  "app_slug":"abcd1234",
  "git": {
    "provider":"github",
    "src_branch":"feature/branch",
    "dst_branch":master, # If the build was triggered by a pull request
    "pull_request_id":32 # If the build was triggered by a pull request
  }
}

• the response given (response status and response body)

Success will be apparent in the UI by a nice green check along with the appropriate status code for each successful delivery, and failure by a not so nice orange triangle and the status code.

Good news is that in addition to adding, editing and removing a webhook, you can redeliver it if you're done with fixing it.

Let us know your best practices! 🙂