Trigger deployments with a webhook call

Today we’re announcing a small, yet sometimes very useful feature inspired by the feedback from our awesome users. With a simple POST request to a certain URL you will now be able to trigger a deployment in a given environment. Let me explain how it works.

We’ve added a new page to the repository settings page, called Webhooks, which lists the current available Webhook triggers. We’ll focus on the new one:

Available configuration settings

As you can see, there’s a whole range of optional settings available for the Webhook that you can just add to the URL as regular arguments. The only required argument is env_id (environment ID), but on that page you should see pre-generated URLs for each of your existing environments in that repository, with correct env_id already pre-filled.

Easiest way to trigger this Webhook from your server / computer would is using curl:

curl -XPOST ''

Once the deployment is triggered, you should receive the following JSON response from the server. You don’t need to do anything with it, but it might be useful for some cases.

  "release": {
    "id": 166213,
    "account_id": 4551,
    "repository_id": 12191,
    "environment_id": 1543,
    "revision": "49534629e930594b265465085ebb5aecc4c6b9bb",
    "deploy_from_scratch": false,
    "comment": "added mysub submodule",
    "author": "Dima Sabanin",
    "created_at": "2014/07/02 12:24:41 -0400",
    "updated_at": "2014/07/02 12:24:41 -0400",
    "skipped": false,
    "deployed_at": null,
    "deployed": false,
    "retries": 0,
    "auto": true,
    "environment_revision": "49534629e930594b265465085ebb5aecc4c6b9bb",
    "environment_branch_name": "master",
    "do_not_notify": false,
    "retried_at": null,
    "state": "waiting",
    "environment_name": "staging"

You can see here that deployment comment was pre-filled with the commit message and that the latest available revision for the branch was used.

But unfortunately things don’t always go the way we plan. In case something goes wrong, like when the revision you’re trying to deploy does not exist or an internal error happened, you should receive 500 or 404 JSON response with some explanation:

  "error": "Failed to trigger deployment, please check incidents created in your account or contact support."

I think that’s about it for this feature. It’s a really simple one and it’s of course not a replacement for a full featured API that we are working on, but it allows for some interesting possibilities. I hope you find it useful in improving your deployment process and taking it to the new levels of automation.

In addition to releasing our API, we plan to keep extending Webhooks that we have available, as nothing beats the simplicity of the Webhook concept.

As usual, we’re always eager to hear what you think. Please let us know what you’re missing in DeployBot, what problems can we solve better and what features would make your work easier and more enjoyable.