*Workflows › Guías*

# Enviar cambios a tu propio sistema

> La API no tiene webhooks. Para mantener otro sistema sincronizado con Filmo sin sondeos, deja que un workflow llame a tu endpoint cuando ocurra algo.

> **Antes de empezar:** Nada de esto es una plantilla: usa un trigger de evento y un paso HTTP. Todos los datos son ficticios y el endpoint está en un dominio de ejemplo reservado. Sustitúyelo por el tuyo.

## Constrúyelo

1. **Crea el workflow** «Nuevo workflow», «Configura un trigger». En la paleta, en «Filmo», abre Pedidos y elige el evento "Pedido reservado".
2. **Añade un filtro para tus propias escrituras** En el trigger, define «Solo cuando»: Origen «es distinto de» API. Sin él, un pedido que reservas por la API REST dispara este workflow, que publica de vuelta en tu sistema, que puede volver a escribir. El filtro es una sola condición, así que no puede excluir también MCP, y un cambio hecho en la app no lleva origen: haz una prueba desde la app y comprueba en el visor de runs que el filtro la deja pasar.
3. **Añade el paso HTTP** Sumar «Enviar petición HTTP». Método POST, URL `https://example.com/filmo-hook`. En el cuerpo, construye un objeto con los campos que necesites e inserta las variables del trigger: el número de pedido, el estado, el contacto y las fechas.
4. **Declara la respuesta** En Respuesta, declara una estructura con el campo que devuelve tu endpoint (por ejemplo `received`, true/false). Una respuesta que no coincida hace fallar el paso, que es lo que quieres si tu sistema responde con una página de error.
5. **Publicar y activar** «Publicar y activar». A partir de ahora, cada pedido que se reserve envía una petición.

## Qué recibe tu endpoint

*El cuerpo, con datos ficticios*

```json
{
  "event": "order.reserved",
  "orderNumber": "P-2026-0042",
  "status": "reserved",
  "customer": "Example Productions",
  "startsAt": "2026-10-20T08:00:00.000Z",
  "endsAt": "2026-10-22T18:00:00.000Z"
}
```

La petición es un POST con `Content-Type: application/json`, un `User-Agent` de `filmo-workflows/1.0` y una cabecera `Idempotency-Key` formada a partir de la ejecución y el paso.

## Haz que tu endpoint sea seguro de repetir

- Filmo puede enviar una petición dos veces si un worker muere después de la llamada y antes de registrar el paso. Trata la `Idempotency-Key` como la clave de la petición: si ya la has visto, responde 2xx sin volver a hacer el trabajo.
- Tu endpoint tiene que ser accesible desde internet público: las direcciones privadas están bloqueadas (consulta la página de peticiones HTTP).
- Responde rápido. El paso se rinde tras 15 segundos sin actividad.
- Una respuesta que no sea 2xx hace fallar el run, y Filmo no reintenta la petición por sí solo. Fíjate en el aviso de fallo, corrige tu endpoint y pulsa Reintentar en el run: vuelve a enviar, desde el paso que falló.
- Si el resto del workflow debe continuar aunque tu sistema esté caído, pon el paso HTTP dentro de un paso Intentar. Después, comprueba el resultado del Intentar y, si falló, crea una tarea o avisa a alguien con el mensaje de error. Sin esa comprobación el fallo es silencioso. Consulta [el paso Intentar](https://docs.filmo.io/es/workflows/errors-and-retries#try).

> **Atención:** Pon un secreto en una cabecera solo si aceptas que cualquiera que pueda abrir el workflow puede leerlo, y que aparece en todas las versiones (los administradores todavía pueden abrir un workflow privado). Haz el workflow privado y usa un token que solo funcione para este endpoint.

## Cuando también necesitas lo contrario

Para iniciar un workflow desde tu sistema, consulta [Iniciar un workflow desde tu propio sistema](https://docs.filmo.io/es/workflows/guides/start-from-your-system). Para leer datos en bloque, o para recoger lo que se le escapó a un push, usa la API como se describe en [Sincronizar datos](https://docs.filmo.io/es/rest-api/guides/syncing-data#push).

---

URL canónica: https://docs.filmo.io/es/workflows/guides/push-to-your-system  
Última actualización: 2026-10-09