The Wishbone bootstrap file has to be extended so we can accept the incoming data, compose the proper message and send it out.

Let's consider following example bootstrap file:

Adding the /travis endpoint

Giving each service a dedicated endpoint simplifies things. It's clean, it allows you to restrict access using dedicated credentials and it already categorizes incoming data.

In order to add the /travis endpoint we need to define another resource in the incoming_webhooks instance. (see line 15):

"^travis$" : users : - travis tokens : [] response : "OK {{uuid}}" urldecoded_field : payload

The key ^travis$ is a regex matching the endpoint we'd like to configure. Users is an array of the usernames allowed access to the endpoint.

Tokens is left empty as we cannot use it since Travis webhook :notifications do not support that.

The response parameter composes the response going to the client which is in this context not that useful.

The Travis webhooks are delivered with a application/x-www-form- urlencoded content type using HTTP POST, with the body including a payload parameter that contains the JSON webhook payload in a URL-encoded format.

By setting the urldecoded_field to payload we instruct Wishbone to expect the incoming data has to be URL-decoded and the parameter of interest is payload . Once the value is acquired, it is send to the defined protocol decoder (line 12) for further processing.

The htpasswd field (line 21) should contain a htpasswd encoded password for user travis. This will be the password the Travis webhook should use to authenticate to this endpoint.