Push changes to your own system

1. 1

   Create the workflow

   «New workflow», «Set up a trigger». In the palette, under «Filmo», open Orders and pick the event "Order reserved".

2. 2

   Add a filter for your own writes

   In the trigger, set «Only when»: Origin «is not equal to» API. Without it, an order you reserve through the REST API fires this workflow, which posts back to your system, which may write again. The filter is a single condition, so it cannot also exclude MCP, and a change made in the app carries no origin: run a test from the app and check in the run viewer that the filter lets it through.

3. 3

   Add the HTTP step

   Add «Send HTTP request». Method POST, URL https://example.com/filmo-hook. In the body, build an object with the fields you need and insert the trigger's variables: the order number, status, contact and dates.

4. 4

   Declare the response

   Under Response, declare a structure with the field your endpoint returns (for example received, true/false). A response that does not match fails the step, which is what you want if your system answers with an error page.

5. 5

   Publish and activate

   «Publish and activate». From now on, each order that is reserved sends one request.

{
  "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"
}

The request is a POST with Content-Type: application/json, a User-Agent of filmo-workflows/1.0 and an Idempotency-Key header made from the run and the step.

• Filmo may send a request twice, if a worker dies after the call and before it records the step. Treat the Idempotency-Key as the key of the request: if you have seen it, answer 2xx without doing the work again.
• Your endpoint has to be reachable from the public internet: addresses that are private are blocked (see the HTTP requests page).
• Answer fast. The step gives up after 15 seconds without activity.
• A non-2xx answer fails the run, and Filmo does not retry the request by itself. Notice it in the failure notice, fix your endpoint, and press Retry on the run: it sends again, from the step that failed.
• If the rest of the workflow must go on even when your system is down, put the HTTP step inside a Try step. After it, test the Try's outcome and, if it failed, create a task or tell someone with the error message. Without that check the failure is silent. See the Try step.

To start a workflow from your system, see Start a workflow from your own system. To read data in bulk, or to catch what a push missed, use the API as described in Syncing data.