ruLog in to Senler

HTTP request step

The HTTP request step is available in contextual and background automations. It sends a request to an external service, waits for the response, and saves selected data to variables.

Configure the request

Open the HTTP request settings in the right panel to see a compact overview. Click Configure request or the pencil icon to open the method and URL dialog.

Under URL parameters or Headers, click Add to enter a name and value in a separate dialog. The pencil beside a row opens it for editing; the trash icon removes it. Expand longer lists with Show all.

For POST, PUT, PATCH, DELETE and OPTIONS, open the Request body dialog and choose JSON, text or a form. Form fields are also added and edited one at a time. GET and HEAD have no body.

Save in a dialog applies its values to the step settings. Cancel, the close icon or Escape dismisses the dialog without changes. When you have finished, save the step using the button in the right panel.

Enter an API key directly in a header or use a project variable. For example, set the Authorization header to Bearer {{project.crm_token}}. URL parameters and form fields are encoded automatically.

For JSON, start with a valid structure and then insert variables:

{
  "customer_id": "{{run.customer_id}}",
  "enabled": "{{project.crm_enabled}}"
}

A variable occupying the entire JSON string keeps its original type, including number, boolean, null, array or object. Inserting it into other text produces a string. Variable contents are never evaluated as another template. Numeric literals in the JSON body are sent without rounding, including large numeric identifiers.

Save the response

Under Save response, click Add to open the response variable dialog. Choose JSON, response text, HTTP status or a header, then select the destination variable. Each rule appears as a short row in the panel; the pencil opens it for editing.

For JSON, choose Single field or Entire JSON. You can enter the path manually. Choose a field from an example, to the right of JSON path, opens a dialog where you can send a test request or paste JSON manually. Clicking a tree field fills in the current rule’s path and returns to Save response. The selected destination variable stays unchanged.

The path /data/items/0/id selects the first array item's id. Choose Entire JSON to save the complete JSON response. In field names, escape / as ~1 and ~ as ~0. Numbers, false, null, arrays and objects keep their types. Choose a suitable variable and, if needed, a nested field. Missing JSON fields or invalid JSON turn a successful HTTP response into a step mapping error.

A contextual automation can write process, project, lead and dialog variables. A background automation can write process and project variables. Selected persistent variables are saved in one operation, so a failed write does not leave a partial result. If saving fails after a successful HTTP request, reprocessing uses the saved response.

Configure errors and retries

Open the Advanced dialog to change the timeout and number of attempts.

The step always has two outputs: Success and Error. Statuses 200–299 count as success when the selected data is saved successfully. Request or mapping failures follow the Error output. Available selected response fields are saved first; missing JSON fields, headers and absent responses are skipped. The Error output then runs. If it has no connection, the run ends with an error and the received data remains in the variables. Saving the HTTP status separately is useful for checking the result.

The time budget is 1–30 seconds including retries. By default, the request runs once. You may allow up to three attempts for network failures and statuses 408, 425, 429 or 5xx. Use retries for requests that are safe to repeat or services supporting Idempotency-Key. A custom Idempotency-Key header is preserved. The system adds its own key only when you have not supplied one. The same key is used for all attempts of a step. If the outcome is unknown after losing contact with the delivery service, automatic resending is blocked: first check the result in the external service.

Delivery uses the webhook service's address checks, protection against access to private networks, rate limits and response size limits. Redirects are not followed automatically. Production URLs must use HTTPS.

HTTP status, duration, attempt count and errors belong to this step execution and appear in automation history. Request headers and keys are not added to the step result.

Test the step

In Save response, click Choose a field from an example to the right of JSON path to open the response field picker. To send a request, switch to the Request tab. The “Test request” field contains a copy of the method, URL, headers and body from the step settings. Edit it directly or paste a complete HTTP request with a full URL or a cURL example. You can also paste just a JSON body: the method, URL, URL parameters and headers come from the step. File reads and shell commands in cURL are not executed.

Replace the variables you need with test values directly in the request. For example, replace "{{run.order_id}}" with 101. An unchanged {{run.order_id}} is sent as text without substitution; this also applies to project and all other variables. If a variable specifies the service address itself, replace it with a full URL. There are no separate run or trigger inputs. Changes in this dialog are not saved to the step settings; “From step settings” restores the original request.

Click “Send request”. This really sends a request to the external service: for example, POST may create a record. Only the test request is executed, once. Variables stay unchanged, neighboring steps do not run, and the result is excluded from automation run history and statistics.

The response shows the HTTP status, duration, headers, and a JSON tree with field names, types, and values. Click a field, object, array, or Entire JSON to fill in the current rule’s path automatically. Saving a rule changes only the step settings. To save text, the HTTP status, or a header, select that source in Save response.

The example is stored on the server separately for each HTTP step and is available to project members with automation access. Reopening the picker, reloading the page or switching devices loads the saved example. All Save response rules in the step share it; it is not included in the published automation. One example of up to 262,144 characters is stored, with large numeric IDs preserved without rounding.

JSON from a test request is saved automatically. Manually pasted JSON is saved when you select a field, close the dialog or click Save example. Invalid JSON does not replace the saved example; Close without saving discards manual changes. Delete example clears this step’s example.

If another window has changed the example, it will not be overwritten: click Load saved example. If the response was received but the example could not be saved, you do not need to repeat the service request — click Save example.

Changing the test request hides the previous result on the Request tab. Send it again to get a new response. The saved example remains available on Sample response and is replaced by a new JSON response or manual input.

Sending a request is optional. “Sample response” lets you paste your own JSON response; entering the path manually in a mapping remains available. /json/order is needed only when the service actually returns an object named json containing an order field. There is no required /json prefix.

A test run of the entire automation sends real requests to external services. Responses can be saved to test process variables; project, lead, and dialog variables stay unchanged during a test.