Build
HTTP requests
The HTTP step calls a URL from a run: to push a change to your own system, or to read from one. It is deliberately simple, and the simplicity has consequences you should know before you build on it.
| Field | What it takes |
|---|---|
| «Method» | GET, POST, PUT, PATCH or DELETE. A new step is a GET. |
| «URL» | A text with variables. There is no separate field for query parameters: write them in the URL. |
| «Headers» | Names and values; values can use variables. |
| «Body» | A JSON value, shown for POST, PUT and PATCH. It is always sent as JSON, with Content-Type: application. |
| «Response» | The type you expect the response to have. Leave it empty to accept anything. |
- The step sends JSON only. There is no form, multipart or raw body, and no way to send a file.
- The palette also offers Custom development, an HTTP request to an endpoint the Filmo team built for you. Only Filmo support configures it; you cannot set it up with this step (see the page on steps).
- There are no helpers for authentication. To authenticate, type a header such as
Authorizationwith its value. - A step created by the palette starts with an empty body that is sent as
{}. A new DELETE, or a POST whose body you left alone, sends a body of{}. - Every request that is not a GET carries an
Idempotency-Keyheader built from the run and the step's position (<runId>:<position>), so a receiver can ignore a repeat. You can override it with your own header. AUser-Agentoffilmo-workflowsis added unless you set one./1. 0
Secrets in headers
There is no store for credentials. A secret you type in a header is saved in the workflow itself, in every version of it, and visible to anyone who can open the workflow. Make the workflow private if it carries a secret, and prefer a token that only works for this one purpose. The value you send is also recorded in the step's input in every run, and it stays in the run history for 90 days after the run ends, visible to whoever can open the workflow's runs; making the workflow private afterwards does not erase it. Treat a secret that was ever sent this way as exposed, and rotate it. A redirect to another site drops Authorization, Proxy-Authorization and Cookie, but not other headers such as an API-key header.
What you get back
Link to this section: What you get back- Only a success is published, and only the body. The step publishes the parsed body of the response as one variable. The status code and the headers are not available to the steps after it.
- A body that is valid JSON is parsed. Anything else is kept as a text. The
Content-Typeof the response is not looked at. An empty body (a 204) is an empty text. A binary body is decoded as text and will be garbled. - If you declared a response type, the body must match it, or the step fails with "the response does not match the declared type" and the path that differs. Declare the fields you will use; extra fields are ignored. Without a declared type the variable has the type Unknown, and the picker will not offer it in typed fields.
When it fails
Link to this section: When it failsOnly a response with a 2xx status is a success. Anything else fails the step, and failing a step ends the run (unless the step is inside a Try): there is no automatic retry for an HTTP error. Most error messages the engine writes are in Spanish whatever the language of the app, and the English below is a translation; the messages about the address, the time, the size and the redirects are in English.
| What happened | What the step reports |
|---|---|
| A non-2xx response, including a redirect with no destination | The request failed with status <n>. The viewer's «Error» tab shows «HTTP status» and «Response»: the response body. |
| The URL has no value in this run | "The field url has no value" |
| The request could not be made (connection, DNS) | "Request failed" |
| The URL is not valid | "The URL is not valid" |
| The address is not allowed | A message in English: "The host … is not allowed", "… resolves to a blocked address", or "Only the http and https protocols are allowed". |
| No answer in time | "The request timed out" |
| The response is too big | "The response exceeds the size limit" |
| More than three redirects | "Too many redirects" |
A 500 from your server is not retried by Filmo. After you fix the cause, press «Retry» on the failed run; it repeats only the failed step. See Errors and retries.
| Limit | Value |
|---|---|
| Methods | GET, POST, PUT, PATCH, DELETE |
| Response size | 5 MB; the read stops there and the step fails |
| Time | 15 seconds without activity on the connection |
| Redirects followed | 3 |
| Ports | Any |
The safety guard
Link to this section: The safety guardA workflow can call any address you type, so every call goes through a guard before and during the request:
- Only
httpandhttpsare allowed. - The names of the local machine and the cloud metadata host are blocked, and so is any name that resolves to a private, loopback, link-local or otherwise reserved address. Every address a name resolves to is checked.
- The address that passed the check is the one the connection uses, so the name cannot be changed to an internal address between the check and the call.
- Redirects are followed by hand, at most three, and every hop passes the same checks.
- The platform can restrict workflows to an allow-list of hosts. That is a setting of the whole platform, not of one workflow.
The guard is a safety net, not a firewall. Do not put on the open internet an endpoint that must not be reachable from Filmo, and keep calls to systems you control.
An example
Link to this section: An exampleA workflow that tells your system when an order is reserved: an event trigger, and one request. All data below is fictitious.
POST https://example.com/filmo-hook
Content-Type: application/json
X-Source: filmo-workflow
{ "event": "order.reserved", "orderNumber": "P-2026-0042" }Declare the response as a structure with the fields you will read. The guide Push changes to your own system builds this end to end.
To start a workflow from your system instead, see Incoming webhooks.
Related pages
Link to this section: Related pagesBuild
Incoming webhooks
A webhook trigger gives the workflow a private address. Your system POSTs JSON to it with a secret, Filmo answers 202 straight away, and a run starts.
Run
Errors and retries
Two different things go wrong in a run: a step reports a problem, or the engine itself breaks. They are treated differently, and the difference is the most important thing on this page.
Build
Data and expressions
You do not write formulas in a workflow. You pick values from lists, and Filmo stores what you picked as a structured expression. This page explains what the picker offers and how the values behave when the run executes.
Was this page helpful?