Configuring POST and GET Request Steps

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

Configurable Fields for POST and GET Request Steps

The following table summarizes the available configuration fields:

Variable Concatenation

Supported text fields and text areas can combine static text with dynamic values. You can reference a variable directly using the {{variableName}} syntax or include it within a string alongside static text. For example:

• Direct variable reference: {{JobID}}
• Variable combined with static text: https://api.com/1/{{JobID}}/

Variable Selector

To reduce errors caused by manual typing and speed up configuration, Mendix Pipelines provides a Variable Selector for supported configuration fields. Typing {{ in a supported field opens the Variable Selector, which displays available variables. The list is dynamically populated with:

• user-defined variables
• outputs from previous pipeline steps
• Mendix-provided variables:
  • {{Mendix.ProjectId}}
  • {{Mendix.TriggerType}}
  • {{Mendix.Branch}} (Git Push only)
  • {{Mendix.Revision}} (Git Push only)

Selecting a variable inserts it into the field.

API Endpoint

Both POST and GET request steps require a Request URL that specifies the endpoint to call. The Request URL supports variable concatenation. The following examples show valid Request URLs:

• Static URL: https://api.example.com/jobs
• URL with a variable: https://api.example.com/jobs/{{JobID}}
• URL with multiple variables: https://api.example.com/jobs/{{ProjectID}}/jobs/{{JobID}}
• URL with variables and static text: https://api.example.com/{{Environment}}/jobs/{{JobID}}/status

HTTP Request 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.

POST and GET request steps support the following header rules:

• You can define up to five headers as key-value pairs.
• Header keys and values support static text, pipeline variables, or a combination of both using the {{variableName}} syntax.
• Header values are resolved when the step starts.
• For GET request steps, header values are fixed and are not re-evaluated during polling.

For example, you can define an Authorization header with the value Bearer {{API_Token}}, or combine static text and variables in a custom header value such as mx-{{Environment}}-{{API_Token}}.

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 and variable concatenation. For example:

{
  "jobId": "{{JobID}}",
  "environment": "{{Environment}}",
  "name": "scan-{{ProjectName}}-{{BuildNumber}}"
}

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 jq-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 jq-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 jq 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}}

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.
• Up to five HTTP headers can be configured.
• The Request Body field does not support the Variable Selector. You must enter variable references manually.
• For GET request steps, header values are resolved once and are not re-evaluated during polling.
• 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.