*Workflows › Construir*

# Peticiones HTTP

> El paso HTTP llama a una URL desde una ejecución: para enviar un cambio a tu propio sistema, o para leer de uno. Es deliberadamente simple, y esa simplicidad tiene consecuencias que conviene conocer antes de construir sobre él.

## Campos

| Campo | Qué se necesita |
| --- | --- |
| «Método» | GET, POST, PUT, PATCH o DELETE. Un paso nuevo es un GET. |
| «URL» | Un texto con variables. No hay un campo aparte para los parámetros de consulta: escríbelos en la URL. |
| «Cabeceras» | Nombres y valores; los valores pueden usar variables. |
| «Cuerpo» | Un valor JSON, que se muestra en POST, PUT y PATCH. Siempre se envía como JSON, con `Content-Type: application/json`. |
| «Respuesta» | El tipo que esperas que tenga la respuesta. Déjalo vacío para aceptar cualquiera. |

- El paso envía solo JSON. No hay formulario, multipart ni cuerpo sin procesar, ni forma de enviar un archivo.
- La paleta también ofrece Desarrollo a medida, una petición HTTP a un endpoint que el equipo de Filmo construyó para ti. Solo el soporte de Filmo lo configura; no puedes configurarlo con este paso (consulta la página de pasos).
- No hay ayudas para la autenticación. Para autenticarte, escribe una cabecera como `Authorization` con su valor.
- Un paso creado desde la paleta empieza con un cuerpo vacío que se envía como `{}`. Un DELETE nuevo, o un POST cuyo cuerpo no has tocado, envía un cuerpo de `{}`.
- Toda petición que no sea GET lleva una cabecera `Idempotency-Key` construida a partir de la ejecución y la posición del paso (`<runId>:<position>`), para que el receptor pueda ignorar una repetición. Puedes sustituirla por tu propia cabecera. Se añade un `User-Agent` de `filmo-workflows/1.0` salvo que indiques uno.

> **Secretos en cabeceras:** No hay almacén de credenciales. Un secreto que escribes en una cabecera se guarda en el propio workflow, en todas sus versiones, y lo ve cualquiera que pueda abrir el workflow. Haz el workflow privado si lleva un secreto, y prefiere un token que solo funcione para ese único fin. El valor que envías también se registra en la entrada del paso en cada ejecución, y permanece en el historial de runs 90 días después de que termine la ejecución, visible para quien pueda abrir las ejecuciones del workflow; hacer el workflow privado después no lo borra. Trata como expuesto un secreto que se haya enviado alguna vez así, y rótalo. Una redirección a otro sitio descarta `Authorization`, `Proxy-Authorization` y `Cookie`, pero no otras cabeceras como una cabecera de clave de API.

## Qué recibes de vuelta

- Solo se publica un éxito, y solo el cuerpo. El paso publica el cuerpo analizado de la respuesta como una variable. El código de estado y las cabeceras no están disponibles para los pasos siguientes.
- Un cuerpo que es JSON válido se interpreta. Cualquier otro se guarda como texto. No se mira el `Content-Type` de la respuesta. Un cuerpo vacío (un 204) es un texto vacío. Un cuerpo binario se decodifica como texto y saldrá ilegible.
- Si declaraste un tipo de respuesta, el cuerpo debe coincidir con él o el paso falla con "la respuesta no coincide con el tipo declarado" y la ruta que difiere. Declara los campos que vayas a usar; los campos extra se ignoran. Sin un tipo declarado, la variable tiene el tipo Desconocido y el selector no la ofrecerá en los campos tipados.

## Cuando falla

Solo una respuesta con estado 2xx es un éxito. Cualquier otra hace fallar el paso, y que falle un paso termina el run (salvo que el paso esté dentro de un Intentar): no hay reintento automático ante un error HTTP. La mayoría de los mensajes de error que escribe el motor están en español sea cual sea el idioma de la app, y el inglés de abajo es una traducción; los mensajes sobre la dirección, el tiempo, el tamaño y las redirecciones están en inglés.

| Qué ha pasado | Qué informa el paso |
| --- | --- |
| Una respuesta que no sea 2xx, incluida una redirección sin destino | `The request failed with status <n>`. La pestaña «Error» del visor muestra «Estado HTTP» y «Respuesta»: el cuerpo de la respuesta. |
| La URL no tiene valor en esta ejecución | "El campo url no tiene valor" |
| No se pudo hacer la petición (conexión, DNS) | "La petición ha fallado" |
| La URL no es válida | "La URL no es válida" |
| La dirección no está permitida | Un mensaje en inglés: "The host … is not allowed", "… resolves to a blocked address" o "Only the http and https protocols are allowed". |
| Sin respuesta a tiempo | "La petición agotó el tiempo de espera" |
| La respuesta es demasiado grande | "La respuesta supera el límite de tamaño" |
| Más de tres redirecciones | "Demasiadas redirecciones" |

Filmo no reintenta un 500 de tu servidor. Cuando corrijas la causa, pulsa «Reintentar» en la ejecución fallida; repite solo el paso fallido. Consulta [Errores y reintentos](https://docs.filmo.io/es/workflows/errors-and-retries).

## Límites

| Límite | Valor |
| --- | --- |
| Métodos | GET, POST, PUT, PATCH, DELETE |
| Tamaño de la respuesta | 5 MB; la lectura se detiene ahí y el paso falla |
| Tiempo | 15 segundos sin actividad en la conexión |
| Redirecciones seguidas | 3 |
| Puertos | Cualquiera |

## La salvaguarda

Un workflow puede llamar a cualquier dirección que escribas, así que cada llamada pasa por una protección antes y durante la petición:

- Solo se permiten `http` y `https`.
- Los nombres de la máquina local y del host de metadatos de la nube están bloqueados, y también cualquier nombre que se resuelva a una dirección privada, de loopback, de enlace local o reservada de otro modo. Se comprueba cada dirección a la que se resuelve un nombre.
- La dirección que pasó la comprobación es la que usa la conexión, así que el nombre no se puede cambiar por una dirección interna entre la comprobación y la llamada.
- Las redirecciones se siguen a mano, como máximo tres, y cada salto pasa las mismas comprobaciones.
- La plataforma puede restringir los workflows a una lista de hosts permitidos. Es un ajuste de toda la plataforma, no de un workflow.

> **Nota:** La protección es una red de seguridad, no un cortafuegos. No expongas en internet abierto un endpoint que no deba ser alcanzable desde Filmo, y limita las llamadas a sistemas que controlas.

## Un ejemplo

Un workflow que avisa a tu sistema cuando se reserva un pedido: un trigger de evento y una petición. Todos los datos de abajo son ficticios.

*Qué envía el paso*

```http
POST https://example.com/filmo-hook
Content-Type: application/json
X-Source: filmo-workflow

{ "event": "order.reserved", "orderNumber": "P-2026-0042" }
```

Declara la respuesta como una estructura con los campos que vas a leer. La guía [Enviar cambios a tu propio sistema](https://docs.filmo.io/es/workflows/guides/push-to-your-system) lo construye de principio a fin.

> **Consejo:** Para iniciar en su lugar un workflow desde tu sistema, consulta [Webhooks entrantes](https://docs.filmo.io/es/workflows/incoming-webhooks).

---

URL canónica: https://docs.filmo.io/es/workflows/http-requests  
Última actualización: 2026-10-09