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.

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
  }
}
Copy code
  • 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! 🙂

No items found.
The Mobile DevOps Newsletter

Explore more topics

App Development

Learn how to optimize your mobile app deployment processes for iOS, Android, Flutter, ReactNative, and more

Bitrise & Community

Check out the latest from Bitrise and the community. Learn about the upcoming mobile events, employee spotlights, women in tech, and more

Mobile App Releases

Learn how to release faster, better apps on the App Store, Google Play Store, Huawei AppGallery, and other app stores

Mobile DevOps

Learn Mobile DevOps best practices such as DevOps for iOS, Android, and industry-specific DevOps tips for mobile engineers

Mobile Testing & Security

Learn how to optimize mobile testing and security — from automated security checks to robust mobile testing and more.

Product Updates

Check out the latest product updates from Bitrise — Build Insights updates, product news, and more.

The Mobile DevOps Newsletter

Join 1000s of your peers. Sign up to receive Mobile DevOps tips, news, and best practice guides once every two weeks.