From 3c9270a4d685c912112aeb0ea7d3c3e528404def Mon Sep 17 00:00:00 2001 From: Olufunke Moronfolu Date: Fri, 6 Mar 2026 14:12:38 +0100 Subject: [PATCH 1/4] Initial doc update for GET and POST requests steps on Mendix Pipelines --- .../deployment/general/mendix-pipelines.md | 21 +++++++++++++++++++ .../deployment/mendix-pipelines.md | 6 ++++++ 2 files changed, 27 insertions(+) diff --git a/content/en/docs/deployment/general/mendix-pipelines.md b/content/en/docs/deployment/general/mendix-pipelines.md index aa8602fe189..7340e8f2eb5 100644 --- a/content/en/docs/deployment/general/mendix-pipelines.md +++ b/content/en/docs/deployment/general/mendix-pipelines.md @@ -167,6 +167,27 @@ Check out a branch. To configure this step, use the drop-down menu to select the Build a deployment package based on the latest major, minor, or patch version of the branch you checked out. The highest version is incremented based on the increment settings specified in this step. +##### GET Request + +Retrieve information from an external API to inform or control the pipeline's next steps. The GET request step requires the following: + +* **Request URL** – The endpoint to query. +* **Initial delay (seconds)** – Time to wait before the first request. Must be between 0 and 10800 seconds. +* **Polling interval (seconds)** – Time between retries. Must be between 5 and 300 seconds. +* **Maximum wait time (seconds)** – Total time to wait before timing out. Must be between 0 and 10800 seconds. + +The GET request step has the following [success criteria](https://jqlang.org/manuallets): + +* **API call succeeds** – The API returns a 2xx response. +* **API output meets condition** – The user-defined condition in jQuery evaluates to true (for example, `.Result = Success`). + +##### POST Request + +Send structured data to an external API to trigger an action or update a system. The POST request step requires the **Request URL**, which is the endpoint to send data to. The [success criteria](https://jqlang.org/manuallets) for the POST request step are: + +* **API call succeeds** – The API returns a 2xx response. +* **API output meets condition** – The user-defined condition in jQuery evaluates to true (for example, `.Result = Success`). + ##### Maia Best Practice Recommender{##recommender} Evaluate the results of the [Maia Best Practice Recommender](/refguide/best-practice-recommender/) within your Mendix Pipeline. You can configure this step to fail the Mendix Pipeline if errors, warnings, deprecations, and/or recommendations are detected. diff --git a/content/en/docs/releasenotes/deployment/mendix-pipelines.md b/content/en/docs/releasenotes/deployment/mendix-pipelines.md index 4434be9013e..75de74c5a29 100644 --- a/content/en/docs/releasenotes/deployment/mendix-pipelines.md +++ b/content/en/docs/releasenotes/deployment/mendix-pipelines.md @@ -12,6 +12,12 @@ To see the current status of the Mendix Pipelines, see [Mendix Status](https://s ## 2026 +### March 12, 2026 + +#### New Features + +* We have added two new steps, [GET request](/developerportal/deploy/mendix-pipelines/#get-request) and [POST request](/developerportal/deploy/mendix-pipelines/#post-request), to Mendix Pipelines. These new steps allow Mendix Pipelines to retrieve and send structured data to external APIs. + ### February 26, 2026 #### New Features From c91f2fb7369c1fca9075376ec0c1c9d14c372e67 Mon Sep 17 00:00:00 2001 From: Olufunke Moronfolu Date: Mon, 9 Mar 2026 15:03:21 +0100 Subject: [PATCH 2/4] Adding the configuration fields to the get and post steps --- .../deployment/general/mendix-pipelines.md | 40 +++++++++++++------ 1 file changed, 27 insertions(+), 13 deletions(-) diff --git a/content/en/docs/deployment/general/mendix-pipelines.md b/content/en/docs/deployment/general/mendix-pipelines.md index 7340e8f2eb5..115d04d6ac2 100644 --- a/content/en/docs/deployment/general/mendix-pipelines.md +++ b/content/en/docs/deployment/general/mendix-pipelines.md @@ -169,24 +169,38 @@ Build a deployment package based on the latest major, minor, or patch version of ##### GET Request -Retrieve information from an external API to inform or control the pipeline's next steps. The GET request step requires the following: +Use the **GET request** step to retrieve data from an external API and use the response to inform or control the next steps in the pipeline. + +The **GET request** step has the following configuration fields: + +| Field | Required? | Description | +| --- | :---: | --- | +| **Request URL** | Yes | Base endpoint to call (for example, `https://api.com/1/app`). | +| **Additional URL path** | No | Path appended to the Request URL (for example, `/123/status`). | +| **Header 1–5 Key / Value** | No | Up to five request headers. You can reference pipeline variables in header values (for example, set `Authorization` to `Bearer $API_Key`). | +| **Success Condition (in jQuery)** | No | Defines success of the API output. Set a jq expression that must evaluate to `true` (for example, `.Result == "Success"`). If empty, the step passes by default and logs: `No success condition set — this step will pass by default`.| +| **Failure Condition (in jQuery)** | No | Defines failure of the API output. If empty, the step passes if the success condition is met; otherwise the step keeps polling until maximum wait time is reached and logs: `No fail condition set — the step will run until success or timeout`. | +| **Result 1–3 (parsing logic to extract output in jQuery)** | No | jq expressions to extract values from the response and store them as step outputs (for example, `.JobId`). | +| **Initial Delay (seconds)** | Yes | Delay before the first call. Range must be between 0 and 10800. | +| **Polling Interval (seconds)** | Yes | Time between retries. Range must be between 5 and 300. | +| **Maximum Wait Time (seconds)** | Yes | Total time to wait before timing out. Range must be between 0 and 10800. | -* **Request URL** – The endpoint to query. -* **Initial delay (seconds)** – Time to wait before the first request. Must be between 0 and 10800 seconds. -* **Polling interval (seconds)** – Time between retries. Must be between 5 and 300 seconds. -* **Maximum wait time (seconds)** – Total time to wait before timing out. Must be between 0 and 10800 seconds. - -The GET request step has the following [success criteria](https://jqlang.org/manuallets): - -* **API call succeeds** – The API returns a 2xx response. -* **API output meets condition** – The user-defined condition in jQuery evaluates to true (for example, `.Result = Success`). +{{% alert color="info" %}} +To learn more about jq, refer to the [jQuery manual](https://jqlang.org/manual). +{{% /alert %}} ##### POST Request -Send structured data to an external API to trigger an action or update a system. The POST request step requires the **Request URL**, which is the endpoint to send data to. The [success criteria](https://jqlang.org/manuallets) for the POST request step are: +Use the **POST request** step to send structured data to an external API to trigger an action or update a system. The POST request step has the following configuration fields: -* **API call succeeds** – The API returns a 2xx response. -* **API output meets condition** – The user-defined condition in jQuery evaluates to true (for example, `.Result = Success`). +| Field | Required? | Description | +| --- | :---: | --- | +| **Request URL** | Yes | Base endpoint to call (for example, `https://api.com/1/apps`). | +| **Additional URL path** | No | Path appended to the Request URL (for example, `/start`). | +| **Header 1–5 Key / Value** | No | Up to five request headers. You can reference pipeline variables in header values (for example, `x-api-key: $API_Key`). | +| **Request body (JSON)** | No | JSON payload to send. Default: `{}`. | +| **Success condition (in jQuery)** | No | Defines success of the API output. Set a jq expression that must evaluate to `true` (for example, `.Result == "Success"`). If empty, the step passes by default and log message shows: `No success condition set — this step will pass by default`. | +| **Result 1–3 (parsing logic to extract output in jQuery)** | No | jq expressions to extract values from the response and store them as step outputs (for example, `.JobId`). | ##### Maia Best Practice Recommender{##recommender} From cf13be7d82e4c78ca7a705b63e93c0cba7c57819 Mon Sep 17 00:00:00 2001 From: Olufunke Moronfolu Date: Tue, 10 Mar 2026 13:17:09 +0100 Subject: [PATCH 3/4] R&D feedback for pipelines release --- .../en/docs/deployment/general/mendix-pipelines.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/content/en/docs/deployment/general/mendix-pipelines.md b/content/en/docs/deployment/general/mendix-pipelines.md index 115d04d6ac2..f73efd2a65b 100644 --- a/content/en/docs/deployment/general/mendix-pipelines.md +++ b/content/en/docs/deployment/general/mendix-pipelines.md @@ -176,10 +176,10 @@ The **GET request** step has the following configuration fields: | Field | Required? | Description | | --- | :---: | --- | | **Request URL** | Yes | Base endpoint to call (for example, `https://api.com/1/app`). | -| **Additional URL path** | No | Path appended to the Request URL (for example, `/123/status`). | -| **Header 1–5 Key / Value** | No | Up to five request headers. You can reference pipeline variables in header values (for example, set `Authorization` to `Bearer $API_Key`). | -| **Success Condition (in jQuery)** | No | Defines success of the API output. Set a jq expression that must evaluate to `true` (for example, `.Result == "Success"`). If empty, the step passes by default and logs: `No success condition set — this step will pass by default`.| -| **Failure Condition (in jQuery)** | No | Defines failure of the API output. If empty, the step passes if the success condition is met; otherwise the step keeps polling until maximum wait time is reached and logs: `No fail condition set — the step will run until success or timeout`. | +| **Additional URL path** | No | Path appended to the Request URL (for example, `$GET Request.Result1 or 123` ). | +| **Header 1–5 Key / Value** | No | Up to five request headers. You can reference pipeline variables in header values (for example, set `Authorization` to `$API_Key`). | +| **Success Condition (in jQuery)** | No | Defines success of the API output. Set a jq expression that must evaluate to `true` (for example, `.Result == "Success"`). If empty, the step passes by default. | +| **Failure Condition (in jQuery)** | No | Defines failure of the API output. If empty, the step passes if the success condition is met; otherwise the step keeps polling until maximum wait time is reached. | | **Result 1–3 (parsing logic to extract output in jQuery)** | No | jq expressions to extract values from the response and store them as step outputs (for example, `.JobId`). | | **Initial Delay (seconds)** | Yes | Delay before the first call. Range must be between 0 and 10800. | | **Polling Interval (seconds)** | Yes | Time between retries. Range must be between 5 and 300. | @@ -196,10 +196,10 @@ Use the **POST request** step to send structured data to an external API to trig | Field | Required? | Description | | --- | :---: | --- | | **Request URL** | Yes | Base endpoint to call (for example, `https://api.com/1/apps`). | -| **Additional URL path** | No | Path appended to the Request URL (for example, `/start`). | +| **Additional URL path** | No | Path appended to the Request URL (for example, `$POST Request.Result1 or 123`). | | **Header 1–5 Key / Value** | No | Up to five request headers. You can reference pipeline variables in header values (for example, `x-api-key: $API_Key`). | | **Request body (JSON)** | No | JSON payload to send. Default: `{}`. | -| **Success condition (in jQuery)** | No | Defines success of the API output. Set a jq expression that must evaluate to `true` (for example, `.Result == "Success"`). If empty, the step passes by default and log message shows: `No success condition set — this step will pass by default`. | +| **Success condition (in jQuery)** | No | Defines success of the API output. Set a jq expression that must evaluate to `true` (for example, `.Result == "Success"`). If empty, the step passes by default. | | **Result 1–3 (parsing logic to extract output in jQuery)** | No | jq expressions to extract values from the response and store them as step outputs (for example, `.JobId`). | ##### Maia Best Practice Recommender{##recommender} From 44362bd0db080a55c5384aec56d08abb8df73375 Mon Sep 17 00:00:00 2001 From: Olufunke Moronfolu Date: Tue, 21 Apr 2026 12:45:04 +0200 Subject: [PATCH 4/4] Doc for POST & GET release for MxPipelines --- .../_index.md} | 33 +--- .../configuring-post-get-steps.md | 173 ++++++++++++++++++ .../deployment/mendix-pipelines.md | 4 +- .../partials/landingpage/latest-releases.html | 2 +- 4 files changed, 179 insertions(+), 33 deletions(-) rename content/en/docs/deployment/general/{mendix-pipelines.md => mendix-pipelines/_index.md} (90%) create mode 100644 content/en/docs/deployment/general/mendix-pipelines/configuring-post-get-steps.md diff --git a/content/en/docs/deployment/general/mendix-pipelines.md b/content/en/docs/deployment/general/mendix-pipelines/_index.md similarity index 90% rename from content/en/docs/deployment/general/mendix-pipelines.md rename to content/en/docs/deployment/general/mendix-pipelines/_index.md index f73efd2a65b..c160366a634 100644 --- a/content/en/docs/deployment/general/mendix-pipelines.md +++ b/content/en/docs/deployment/general/mendix-pipelines/_index.md @@ -1,7 +1,7 @@ --- title: "Mendix Pipelines" url: /developerportal/deploy/mendix-pipelines/ -weight: 80 +weight: 20 description: "Describes how to design, implement, and review pipelines using the Pipelines feature in the Mendix Portal" aliases: - /developerportal/deploy/pipelines/ @@ -169,38 +169,11 @@ Build a deployment package based on the latest major, minor, or patch version of ##### GET Request -Use the **GET request** step to retrieve data from an external API and use the response to inform or control the next steps in the pipeline. - -The **GET request** step has the following configuration fields: - -| Field | Required? | Description | -| --- | :---: | --- | -| **Request URL** | Yes | Base endpoint to call (for example, `https://api.com/1/app`). | -| **Additional URL path** | No | Path appended to the Request URL (for example, `$GET Request.Result1 or 123` ). | -| **Header 1–5 Key / Value** | No | Up to five request headers. You can reference pipeline variables in header values (for example, set `Authorization` to `$API_Key`). | -| **Success Condition (in jQuery)** | No | Defines success of the API output. Set a jq expression that must evaluate to `true` (for example, `.Result == "Success"`). If empty, the step passes by default. | -| **Failure Condition (in jQuery)** | No | Defines failure of the API output. If empty, the step passes if the success condition is met; otherwise the step keeps polling until maximum wait time is reached. | -| **Result 1–3 (parsing logic to extract output in jQuery)** | No | jq expressions to extract values from the response and store them as step outputs (for example, `.JobId`). | -| **Initial Delay (seconds)** | Yes | Delay before the first call. Range must be between 0 and 10800. | -| **Polling Interval (seconds)** | Yes | Time between retries. Range must be between 5 and 300. | -| **Maximum Wait Time (seconds)** | Yes | Total time to wait before timing out. Range must be between 0 and 10800. | - -{{% alert color="info" %}} -To learn more about jq, refer to the [jQuery manual](https://jqlang.org/manual). -{{% /alert %}} +Use the **GET request** step to retrieve data from an external API and use the response to inform or control the next steps in the pipeline. For information about configuring GET Request steps, refer to [Configuring POST and GET Request Steps](/developerportal/deploy/configuring-post-get-request-steps/). ##### POST Request -Use the **POST request** step to send structured data to an external API to trigger an action or update a system. The POST request step has the following configuration fields: - -| Field | Required? | Description | -| --- | :---: | --- | -| **Request URL** | Yes | Base endpoint to call (for example, `https://api.com/1/apps`). | -| **Additional URL path** | No | Path appended to the Request URL (for example, `$POST Request.Result1 or 123`). | -| **Header 1–5 Key / Value** | No | Up to five request headers. You can reference pipeline variables in header values (for example, `x-api-key: $API_Key`). | -| **Request body (JSON)** | No | JSON payload to send. Default: `{}`. | -| **Success condition (in jQuery)** | No | Defines success of the API output. Set a jq expression that must evaluate to `true` (for example, `.Result == "Success"`). If empty, the step passes by default. | -| **Result 1–3 (parsing logic to extract output in jQuery)** | No | jq expressions to extract values from the response and store them as step outputs (for example, `.JobId`). | +Use the **POST request** step to send structured data to an external API to trigger an action or update a system. For information about configuring POST Request steps, refer to [Configuring POST and GET Request Steps](/developerportal/deploy/configuring-post-get-request-steps/). ##### Maia Best Practice Recommender{##recommender} diff --git a/content/en/docs/deployment/general/mendix-pipelines/configuring-post-get-steps.md b/content/en/docs/deployment/general/mendix-pipelines/configuring-post-get-steps.md new file mode 100644 index 00000000000..00fd0736c50 --- /dev/null +++ b/content/en/docs/deployment/general/mendix-pipelines/configuring-post-get-steps.md @@ -0,0 +1,173 @@ +--- +title: "Configuring POST and GET Request Steps" +url: /developerportal/deploy/configuring-post-get-request-steps/ +weight: 20 +description: "Describes how to configure the POST and GET request steps in Mendix Pipelines." +--- + +## Introduction + +POST and GET request steps let Mendix Pipelines call external systems over HTTPS to trigger actions, send data, or retrieve status information or results. Typical use cases include: + +* triggering an action in an external system +* sending data to an external API +* polling an external system until a process reaches a terminal state +* extracting response values for use in later pipeline steps +* running external test suites, quality checks, or security scans +* collecting data before promoting a package to production + +{{% alert color="warning" %}} +Mendix Pipelines sends requests exactly as you configure them and does not validate: + +* HTTP headers +* JSON payload syntax or structure +* required fields +* condition expressions +* whether the request matches the external system's API specification + +Before running a request step in Mendix Pipelines, Mendix recommends testing the API call in an API client such as Postman, Bruno, or Insomnia. These tools provide JSON validation, formatting, and immediate feedback from the external system. +{{% /alert %}} + +## Configurable Fields for POST and GET Request Steps + +The following table summarizes the available configuration fields. + +| Field | Required? | Description | Example | +|------------------------|---:|-------------------------------------------------------------------------------------------------|-----------| +| **Base URL path** | Yes | Base endpoint of the external system to call. Must start with the protocol. Must end with `/` when using the **Additional URL Path**. | `https://api.com/1/JobID/` | +| **Additional URL path** | No | String or variable to append to the **Base URL Path**. Can reference a stored variable. | `$POST Request.Result1` or `a12f3` | +| **HTTP header key-value pairs** | No | HTTP headers to include with the request as metadata. Values can reference stored variables. | `Authorization` = `$API_Key` | +| **Variable extraction** | No | Expressions to extract values from the response body and store them as reusable output variables. | `.JobId` | +| **Success condition** | No | Success condition that must evaluate to `true` to continue to the next pipeline step. Must be a jQuery expression. | `.Result == "Success"` | +| **Failure condition** | No (GET only) | Failure condition that must evaluate to `true` to stop polling and fail the pipeline. Must be a jQuery expression. | `.Result == "Failed"` | +| **Polling delay** | Yes (GET only) | Time in seconds before the first GET request runs. Range: 0–10800. | `30` | +| **Polling interval** | Yes (GET only) | Time in seconds between GET retries. Range: 5–300. | `10` | +| **Polling duration** | Yes (GET only) | Maximum time in seconds to poll before timing out and failing. Range: 0–10800. | `600` | + +## API Endpoint + +Both POST and GET request steps require an endpoint defined as a URL. Mendix Pipelines builds the endpoint as `Base URL Path + Additional URL Path`. The endpoint can be: + +* a static URL +* a dynamic URL that includes one pipeline variable at the end + +When you use a variable in the URL, the following rules apply: + +* You can use only one variable. +* The variable must be the last part of the URL. +* You cannot append additional text after the variable (no concatenation). + +## HTTP Headers + +HTTP headers can be added along with the API calls to provide metadata for the request, such as content type, authentication credentials, or other API-specific values. Mendix recommends storing secrets such as API keys or tokens as [pipeline variables](/developerportal/deploy/mendix-pipelines/#variable-tab). + +POST and GET request steps support the following header rules: + +* You can define up to five headers as key-value pairs. +* Header names must be static strings. +* Header values can be static strings or predefined pipeline variables. +* Header values do not support string concatenation. +* Header values are resolved when the step starts. +* For GET request steps, header values are fixed and are not re-evaluated during polling. + +If an authentication scheme requires a prefix such as `Bearer`, include the prefix in the variable value. For example, the variable `$app1_BearerToken` can contain the value `Bearer aDbEcF123`. + +## Request Body (POST Only) + +The request body is available for POST request steps only. It is a plain text input that defines the JSON payload that Mendix Pipelines sends to the external system when a POST request runs. This payload can be used to start a job, trigger a scan, create a record, or update data. + +### Dynamic Values in the Request Body + +The request body supports static JSON content. It does not support: + +* inserting variables into individual JSON fields +* inline variable substitution +* string concatenation +* expressions inside the payload + +If the external API requires dynamic values, such as identifiers or environment-specific parameters, consider one of the following alternatives: + +* URL parameters +* HTTP headers where pipeline variables are supported +* logic in the external system after it receives the request + +## Success and Failure Conditions + +Success and failure conditions define how Mendix Pipelines interprets the response returned by an external system and decides whether a pipeline step should continue or stop. + +Conditions are evaluated against the JSON response body using jQuery-style expressions (for example, `.Result == "Success"`). These expressions can: + +* check whether fields exist +* compare values +* verify that the response indicates a specific status + +### POST Request Conditions + +A POST request step supports a success condition only. When a POST request runs, Mendix Pipelines sends the request once and waits for the response. After the response is received, the success condition is evaluated: + +* If the success condition is `true`, the pipeline continues. +* If `false`, the pipeline fails and stops. + +POST request steps do not retry or wait. For this reason, the success condition typically checks whether the external system accepted the request, not whether the full downstream process has completed. + +If no success condition is defined for a POST request step, the step is considered successful as long as the HTTP request completes without a technical error. + +### GET Request Conditions + +GET request steps are used to poll an external system until the action it is performing has completed. + +A GET request step supports both a success condition and a failure condition: + +* **Success condition** – when met, the step completes successfully and the pipeline continues. +* **Failure condition** – when met, the step fails immediately and the pipeline stops. + +If neither condition is met, the pipeline continues polling until the configured polling duration is reached. + +Mendix recommends basing success and failure conditions on real API responses captured in an API client before configuring them in a pipeline. + +#### GET Request Polling + +Polling occurs each time the GET request runs and controls when and how often the GET request repeats. All of these variables must be defined before the GET request step can run: + +* Polling delay +* Polling interval +* Polling duration + +## Output Extraction to Store as Pipeline Variables + +POST and GET request steps can extract values from the response body and store them as pipeline variables which are managed in the **Variables** tab for use in later steps. + +A use case is chaining a POST request and a GET request. For example, a POST request can return an identifier that is stored as an output variable and then reused in the URL of a later GET request. + +Each POST or GET request step can define up to three extracted output variables. + +Each output slot is populated by a jQuery-style expression evaluated against the response body returned by the external system. The expression determines which value is stored. For example, an expression can reference a specific value such as `.JobID` or use JQuery logic to extract an outcome value as a reusable variable. + +Output variables are automatically named and you cannot assign custom name or change the names. Mendix Pipelines exposes extracted values using a fixed naming pattern such as: + +* `$GET Request.Output_1` +* `$POST Request.Output_2` + +{{% alert color="warning" %}} +Mendix Pipelines does not validate whether an extraction expression matches the response, nor does it provide tooling to inspect the response structure interactively. + +If the response format changes or does not match expectations, extracted values can be empty or incorrect. Mendix recommends validating response structures in an API client before configuring extraction expressions in a pipeline. +{{% /alert %}} + +## Known Limitations + +POST and GET request steps currently support the following constraints: + +* A pipeline can contain at most one POST request step and one GET request step. +* A dynamic endpoint can contain only one variable, and that variable must be the last part of the URL. +* Additional text cannot be appended after a variable in the URL. +* Up to five HTTP headers can be configured. +* Header names must be static. +* Header values support only static strings or predefined pipeline variables. +* Header values do not support concatenation. +* For GET request steps, header values are resolved once and are not re-evaluated during polling. +* The POST request body supports only static JSON content. +* The request body does not support inline variable substitution, concatenation, or expressions. +* Each request step can extract up to three output values. +* Output variable names are generated automatically and cannot be customized. +* Mendix Pipelines does not validate request configuration, payload structure, or extraction expressions before the step runs. diff --git a/content/en/docs/releasenotes/deployment/mendix-pipelines.md b/content/en/docs/releasenotes/deployment/mendix-pipelines.md index 75de74c5a29..9f4ea8db69d 100644 --- a/content/en/docs/releasenotes/deployment/mendix-pipelines.md +++ b/content/en/docs/releasenotes/deployment/mendix-pipelines.md @@ -12,11 +12,11 @@ To see the current status of the Mendix Pipelines, see [Mendix Status](https://s ## 2026 -### March 12, 2026 +### April 23, 2026 #### New Features -* We have added two new steps, [GET request](/developerportal/deploy/mendix-pipelines/#get-request) and [POST request](/developerportal/deploy/mendix-pipelines/#post-request), to Mendix Pipelines. These new steps allow Mendix Pipelines to retrieve and send structured data to external APIs. +* We have added two new steps, [GET request](/developerportal/deploy/mendix-pipelines/#get-request) and [POST request](/developerportal/deploy/mendix-pipelines/#post-request), to Mendix Pipelines. These new steps allow Mendix Pipelines to retrieve and send structured data to external APIs. For information about how to configure these steps, refer to [Configuring POST and GET Request Steps](/developerportal/deploy/configuring-post-get-request-steps/). ### February 26, 2026 diff --git a/layouts/partials/landingpage/latest-releases.html b/layouts/partials/landingpage/latest-releases.html index a6b13aad26b..7f6b4b85084 100644 --- a/layouts/partials/landingpage/latest-releases.html +++ b/layouts/partials/landingpage/latest-releases.html @@ -14,7 +14,7 @@

Latest Releases

  • Deployment -

    March 1, 2026

    +

    April 23, 2026

  • Catalog Release 2.150.0