Webhooks & Events
React to approvals, mentions, and uploads in real time — no code required, or a little code if you need it.
Webhooks & Events
Open the space menu in the top-left corner and choose Webhooks to set up automation rules — no code required for the simple cases, and a small sandboxed function when you need one.
The Webhooks dialog, listing three rules with different actions and a successful run.
What can trigger a rule
Pick an event when you create a rule. You can also scope a rule to one Base, or leave it space-wide.
| Event | Fires when |
|---|---|
| New Record | A record is created and merges into a Base |
| @AI mention | Someone @mentions an agent in a comment |
| Changes requested | A reviewer sends a change request back for revisions |
| Asset uploaded | A file is uploaded that Busabase can't read the text of yet (e.g. an image or a scanned PDF) — handy for wiring up an external OCR or transcription step |
What a rule can do
Every rule does one of three things:
| Action | What happens |
|---|---|
| Webhook | Sends a signed HTTP POST to a URL you provide — the classic "notify another system" webhook |
| Notify agent | Same signed POST, aimed at your AI agent's endpoint, so it can pick up the work |
| Run function | Runs a small piece of JavaScript you write, right inside Busabase — no server of your own required |
Webhook and Notify agent rules just need a URL (and, optionally, a secret Busabase uses to sign the request so the receiving end can verify it really came from you).
Writing a function
Run function is the most flexible option: you write a short script that receives the event as input and can call fetch(url, options) to reach out to any other service directly — Slack, a ticketing system, your own API, anything with a URL.
The function editor: code, a helper note on what's available, and the timeout setting.
A function can:
- Read
input— the event's data (record fields, the base it happened in, and so on) - Call
console.log(...)— anything you log shows up later in the delivery log, which is the easiest way to debug a rule - Call
fetch(url, options)as many times as it needs (up to 10 calls) to notify other systems, look something up, or chain a couple of requests together returna value — it's just recorded for your own reference, nothing more happens with it
You also set a timeout (100ms–5000ms) for how long the whole function is allowed to run, including any fetch calls it makes.
Keeping it safe
A function runs in an isolated sandbox — it can't read your files, your environment variables, or anything else on the server it's running on. The only thing it can touch is the network, through fetch, and even that is guarded: requests aimed at your own internal network (localhost, private IP ranges, or cloud infrastructure addresses) are blocked automatically. A function is meant to talk to the outside world, not to probe your own infrastructure.
Checking whether it worked
Every rule keeps a short history of its recent runs — expand a rule to see it. A Success entry shows whatever you logged; a Failed entry shows the error, so you can see exactly what went wrong and fix it.
A rule's delivery log, showing a successful run with its logged output.
Use the Test now button any time to fire a rule immediately with a realistic sample payload — no need to wait for the real event to happen, and it works even while the rule is still turned off.
See also: Core Concepts · Quick Start · REST API