The inbound automation hook
Firing one of your rules from another tool, and exactly what each status code means.
Set an automation's trigger to Another tool calls this rule's URL and it gets an address of its own:
POST https://noots.ai/api/automations/hook/<token>
Authentication
The secret in the URL is the credential. There is no header and no signature to compute. That token fires that one rule and nothing else, so the blast radius of a leaked URL is a single automation — but treat it like a password all the same, and use Rotate the moment you suspect it.
The body
- Must be a JSON object. An array, a string, a number or
nullis refused. - An empty body is fine — a legitimate ping. The rule fires with nothing to read.
- Up to 64,000 bytes.
- Your fields are readable in the rule as
{payload.field}in message text, and as conditions on Payload.
Responses
| Status | Means |
|---|---|
| 200 | It arrived. The body is { received, ran, reason, detail } — reason is ok (it ran), skipped (one of your conditions ruled it out, and detail names which) or quota (the workspace has used its automation runs this month). |
| 400 | The body was unreadable, wasn't JSON, or wasn't a JSON object. |
| 404 | The token is unknown — or the rule is switched off, out of plan, or no longer triggered by a webhook. |
| 405 | You sent a GET. Only POST does anything. |
| 413 | The body was over 64,000 bytes. |
| 500 | The rule's own actions failed. detail says how. |
| 503 | Noots is in read-only mode, or webhooks are paused platform-wide. Carries retry-after, and nothing was recorded — retry. |
A distinct code for "this token is real but the rule is off" would let anybody with a list of guesses find out which tokens exist. So an unknown token and a disabled rule are given the same answer deliberately. If you need to know whether your rule is off, look at it in Noots — where you're authenticated.
A rule that arrived and was filtered out by its own conditions is a success — it is your rule working as written — so it gets a 200 with ran: false. Read the ran field, not the status code, if you care which happened.
The rule's card counts calls received, and that counter is bumped even for a disabled rule — so you can always tell "nothing ever arrived" apart from "everything that arrived was filtered out". A GET deliberately tells you nothing either way.
Rate limit: 60 requests per minute per IP, its own budget, separate from the v1 API's. Over it you get a 429 with retry-after: 60.