One common use case that currently often requires a script is calling an external webhook from an Automation Rule.
Many automations don’t actually need JavaScript logic inside Fibery - it only need to notify an external automation tool, such as n8n, Make… when an entity reaches a certain state.
For example:
When Creative Task status becomes “Ready”
→ call webhook
→ send selected fields as payload
Right now, this requires a Script Action only because there is no native “Call Webhook / Send HTTP Request” action in automation rules.
A no-code Webhook Action could be much safer and simpler:
- choose URL;
- choose method, usually POST;
- select fields to include in the payload;
- optionally add static headers;
- optionally include entity id, type, public URL, changed fields, previous values;
- see execution history and response status.
This would cover many real integration cases without allowing arbitrary JavaScript execution inside Fibery. It would also fit well with the current security model. Scripts can effectively have too much power, but a controlled Webhook Action would be much more limited:
- no custom JS;
- no direct Fibery API calls from inside the automation;
- no hidden complex logic;
- payload is explicit and visible;
- external systems can use their own restricted API tokens;
- admins could optionally restrict allowed domains or enable this action with a workspace-level toggle.
For teams like ours, this would remove a big bottleneck. We have trusted Space Architects who build operational automations, but they often only need to trigger external workflows, not write code in Fibery [but they limited with ultra basic automations] .
So a native “Call Webhook / Send HTTP Request” action would be a very useful middle ground between basic no-code actions and full Script Actions.