|
| 1 | +--- |
| 2 | +title: "Mendix Deployment Webhooks" |
| 3 | +linktitle: "Deployment Webhooks" |
| 4 | +url: /developerportal/deploy/webhooks/ |
| 5 | +weight: 75 |
| 6 | +description: "Creating a Webhook to trigger actions from the Mendix cloud" |
| 7 | +tags: ["Mendix cloud", "Webhooks", "CI/CD", "Pipeline"] |
| 8 | +--- |
| 9 | + |
| 10 | +{{% alert color="warning" %}} |
| 11 | +This feature is in Beta. For more information on Beta products, see [Beta Releases](/releasenotes/beta-features/). |
| 12 | +{{% /alert %}} |
| 13 | + |
| 14 | +## 1 Introduction |
| 15 | + |
| 16 | +Mendix deployment webhooks allow you to send information about your Mendix app to an external app or workflow. This can be used, for example, to trigger an automated CI/CD workflow when a new change is committed to the Team Server. |
| 17 | + |
| 18 | +Mendix provides webhooks to send project information when the following events happen to your app: |
| 19 | + |
| 20 | +* On package upload – when a deployment package is available in the Developer Portal — this includes creating a package from the Teamserver |
| 21 | +* Team Server push – when a new commit is pushed to the Team Server — this will only be triggered if your app is stored in a Git repository |
| 22 | + |
| 23 | +The webhooks contain a retry mechanism if an error response is received from the endpoint to ensure that the trigger reaches the endpoint. |
| 24 | + |
| 25 | +{{% alert color="info" %}} |
| 26 | +The deployment webhooks are set up and work independently of the [webhooks used for Sprints and stories](/developerportal/collaborate/general-settings/#webhooks), which are deprecated. |
| 27 | +{{% /alert %}} |
| 28 | + |
| 29 | +## 2 Configuring a Webhook{#setting-up} |
| 30 | + |
| 31 | +### 2.1 Creating a New Webhook |
| 32 | + |
| 33 | +To set up a webhook, do the following: |
| 34 | + |
| 35 | +1. Open your app in the Developer Portal. |
| 36 | +1. Open the **Webhooks** page from the left-hand menu. |
| 37 | + |
| 38 | + You will see any current webhooks with an indication of whether they are active or inactive. An inactive webhook will not send any payloads to the endpoint. |
| 39 | + |
| 40 | +1. Click **New Webhook**. |
| 41 | +1. Enter the following information: |
| 42 | + * **Webhook Name** – a name, so you can identify the webhook |
| 43 | + * **URL** – the endpoint which will receive the payload when one of the event types selected in **Available Events** occurs |
| 44 | + * **Validation Secret** – a secret which is shared with the endpoint to verify that it has been triggered by this webhook — see [Verifying Your Webhook](#verify-webhook), below for more information. If you leave this blank, a secret will be generated automatically for you — you can see the generated value if you go back in to edit the webhook. |
| 45 | + * **Available Events** – the event or events which will trigger the webhook to send information to the endpoint. You can see more information about these events in the sections below |
| 46 | + * **Custom Headers** – a **Key**/**Value** pair which is sent as an HTTP header to the endpoint |
| 47 | + |
| 48 | +You can edit or delete an existing webhook by clicking the ellipsis, **…**, in the **Action** column for the webhook you want to change and then select **Edit Webhook** or **Delete Webhook**. |
| 49 | + |
| 50 | +### 2.2 Editing an Existing Webhook |
| 51 | + |
| 52 | +If you select **Edit Webhook** from the ellipsis, **…**, in the **Action** column for a webhook you want to change, you have the following actions available to you: |
| 53 | + |
| 54 | +* You can update **Webhook Name**, **URL**, and **Validation Secret** — click **Save** to save the changes. |
| 55 | +* You can add or delete **Custom Headers** — click **Save** to save the changes. |
| 56 | + |
| 57 | + {{% alert color="info" %}}You cannot change the value of an existing custom header. If you want to change the value, delete the existing header and add a new one with the same key.{{% /alert %}} |
| 58 | + |
| 59 | +* Click **Test Webhook** to send a test payload to the endpoint specified under **URL**. |
| 60 | +* Click **(De)activate Webhook** to switch deactivate an active webhook or activate an inactive webhook. |
| 61 | +* Click **Delete Webhook*** to completely remove the webhook. |
| 62 | + |
| 63 | +## 3 Webhook Headers |
| 64 | + |
| 65 | +Every POST payload contains the following delivery information as part of the header: |
| 66 | + |
| 67 | +* **connection** – `close`, indicating that there is no further information for this HTTP request |
| 68 | +* **content-length** – the size of the HTTP request in bytes, for example `475` |
| 69 | +* **webhook-signature** – the signature of the webhook in the format `<version>,<signature>`, for example `v1,Ay2spGBdE7i6OzNkFgTDnGfqgZT0WonCFoBMt8V3YiQ=` — see [Verifying Your Webhook](#verify-webhook), below for more information |
| 70 | +* **webhook-id** – a unique identifier for this webhook trigger, for example `msg_2M605iBQRge9hTgpYg7fKXQubaw` |
| 71 | +* **user-agent** – the user agent used to process this trigger. |
| 72 | +* **webhook-timestamp** – the time the webhook was triggered, for example `1677072542` |
| 73 | +* **content-type** – `application/json` |
| 74 | +* **accept** – `*/*` |
| 75 | +* **host** – the host part of the endpoint URL, for example `gitlab.com` |
| 76 | + |
| 77 | +In addition, you can add your own custom headers. See [Setting Up a Webhook](#setting-up) for more information. |
| 78 | + |
| 79 | +{{% alert color="info" %}} |
| 80 | +The order of these headers is not guaranteed. |
| 81 | +{{% /alert %}} |
| 82 | + |
| 83 | +### 3.1 Verifying Your Webhook{#verify-webhook} |
| 84 | + |
| 85 | +You will want to verify that your endpoint has received a payload from Mendix and that the request has not been generated or intercepted by a bad actor. |
| 86 | + |
| 87 | +This verification is enabled through the `webhook-signature` which is sent in the webhook header. It is generated using the **Validation Secret** you provided when you set up the webhook in combination with the payload of the trigger using [HMAC-SHA256](https://en.wikipedia.org/wiki/HMAC) authentication. |
| 88 | + |
| 89 | +To verify the the signature, you need to reconstruct it and then compare it with the **webhook-signature** in the webhook header. This is done as follows: |
| 90 | + |
| 91 | +1. Construct a string containing the signed content which is the `{webhook-id}.{webhook-timestamp}.{webhook payload}`. Note the full-stop (`.`) between the three elements. |
| 92 | +1. Calculate the **webhook-signature** using the HMAC-SHA256 function for your language and the **Validation Secret** you set up for the Webhook. |
| 93 | +1. Ensure the result is base64 encoded. |
| 94 | + |
| 95 | + For example, in a bash script this might be: |
| 96 | + |
| 97 | + ```bash {linenos=false} |
| 98 | + WEBHOOK_ID=# from the header |
| 99 | + WEBHOOK_TIMESTAMP=# from the header |
| 100 | + PAYLOAD=# payload of the message |
| 101 | + VALIDATION_SECRET=# set when creating the webhook in the Developer Portal |
| 102 | + |
| 103 | + # to generate the signature: |
| 104 | + printf '%s.%s.%s' "$WEBHOOK_ID" "$WEBHOOK_TIMESTAMP" "$PAYLOAD" | openssl dgst -sha256 -binary -hmac "$VALIDATION_SECRET" | openssl base64 |
| 105 | + ``` |
| 106 | + |
| 107 | +1. Compare **calculated-signature** with **webhook-signature** to ensure that they match. Note that the **webhook-signature** is prefixed by a version and a delimiter. For example, the signature for `v1,f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8=` is just `f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8=` |
| 108 | + |
| 109 | +When verifying your webhook signature, bear the following in mind: |
| 110 | + |
| 111 | +* The signature list **webhook-signature** usually contains a single signature. If there is more than one signature, you should use the first signature, which is calculated using the latest validation secret. |
| 112 | +* You should use a constant-time string comparison method in order to prevent timing attacks. |
| 113 | +* You should also verify that **webhook-timestamp** is within your tolerance for the current system time, to ensure you are not receiving timestamp attacks where old webhook payloads are being sent to your endpoint. |
| 114 | + |
| 115 | +## 4 Package Upload to Developer Portal |
| 116 | + |
| 117 | +When you [upload a package to the Developer Portal](/developerportal/deploy/environments/#package-repository) (including creating a package from the Teamserver), and the webhook responds to the event **On package upload**, request content containing a payload with the following format will be sent to the configured endpoint: |
| 118 | + |
| 119 | +```json {linenos=false} |
| 120 | +{ |
| 121 | + "eventType": "package.uploaded", |
| 122 | + "modelVersion": "0.0.19.62e3d711", |
| 123 | + "name": "main-0.0.19.62e3d711.mda", |
| 124 | + "projectId": "f60650eb-230a-4419-a6af-b3668fc82d5d", |
| 125 | + "runtimeVersion": "9.18.1.54902", |
| 126 | + "uploadTime": "2023-02-23T10:25:21.3896Z", |
| 127 | + "uploaderId": "4bcafd1c-dac8-4335-b401-06ebe86f7851" |
| 128 | +} |
| 129 | +``` |
| 130 | + |
| 131 | +If you need a specific package id for an API call, you will need to use the **Retrieve Packages** call of the [Build API](/apidocs-mxsdk/apidocs/build-api/) to find all the packages and then use the **name** value to find the latest package information for the package you want. |
| 132 | + |
| 133 | +{{% alert color="info" %}} |
| 134 | +Ensure you use the correct key names if using this payload information to call other Mendix APIs. The data may be labelled differently in the API. |
| 135 | +{{% /alert %}} |
| 136 | + |
| 137 | +## 5 Teamserver Push (Git) |
| 138 | + |
| 139 | +When you push a model change to the [Git Team Server](/developerportal/collaborate/team-server/), and the webhook responds to the event **Teamserver push (Git)**, request content containing a payload with the following format will be sent to the configured endpoint: |
| 140 | + |
| 141 | +```json {linenos=false} |
| 142 | +{ |
| 143 | + "after": "4b76061182bf183281b5107cd753c6071ed00040", |
| 144 | + "before": "0b9cb7a3e9a5ccfffa6c79435441999543ccb8c9", |
| 145 | + "branchName": "main", |
| 146 | + "commits": [ |
| 147 | + { |
| 148 | + "authorDate": "2022-12-08T16:15:52+01:00", |
| 149 | + "authorEmail": "uria.abrams@example.com", |
| 150 | + "authorName": "Uria Abrams", |
| 151 | + "id": "4b76061182bf183281b5107cd753c6071ed00040", |
| 152 | + "mendixVersion": "9.20.2.1234", |
| 153 | + "message": "Commit the changes", |
| 154 | + "relatedStories": [ |
| 155 | + { |
| 156 | + "id": "MS-1234" |
| 157 | + } |
| 158 | + ] |
| 159 | + } |
| 160 | + ], |
| 161 | + "eventType": "teamserver.push", |
| 162 | + "projectId": "9bcd62a6-9c19-4c7f-a5ae-49182c67f80f", |
| 163 | + "repositoryType": "git" |
| 164 | +} |
| 165 | +``` |
| 166 | + |
| 167 | +The **after**, **before**, and **id** values are git commit hashes. In most cases, you will want to use the **after** hash which is the last commit on the branch. |
| 168 | + |
| 169 | +{{% alert color="info" %}} |
| 170 | +Ensure you use the correct key names if using this payload information to call other Mendix APIs. The data may be labelled differently in the API. |
| 171 | +{{% /alert %}} |
| 172 | + |
| 173 | +## 6 Logging |
| 174 | + |
| 175 | +You will see [log messages](/developerportal/operate/logs/) in the Developer Portal from the creation or update of your webhooks. |
| 176 | + |
| 177 | +We do not create a log message for when a webhook is triggered. |
0 commit comments