Webhooks

Webhooks connect Nodaro to your other systems in both directions. A Webhook Trigger node gives a workflow a URL that any system can call to start a run, a Schedule Trigger runs it on a timetable, and a Webhook Output node sends a run's results to your server. Nodaro does not call you back on its own: to learn that a run ended, poll it, or end the workflow with a Webhook Output node.

Endpoints

Start a workflow from an HTTP call

curl -s -X POST "https://app.nodaro.ai/v1/webhooks/$WEBHOOK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"prompt": "a lighthouse in a storm", "imageUrl": "https://example.com/lighthouse.jpg"}'

Each webhook trigger accepts 10 requests per minute. The limit is separate from your API tokens' limits.

Typical callers are a payment system that starts an onboarding video when a customer signs up, a code repository that asks for a release-notes summary, a content system that publishes a new article, or a no-code automation tool.

What a triggered run executes

• A trigger wired to something runs only its branch: the nodes downstream of the trigger, plus every node those nodes need as input.
• A trigger wired to nothing runs the whole workflow.
• So one workflow can carry several triggers, each starting its own branch.
• "Wired" means anything that feeds another node: a drawn connection, a node inside a Group, or a field mapping.
• Runs from the editor, the API and published apps are not limited by triggers. They run what they always run.

A trigger created by hand through the API names no node. Nodaro then uses the only Webhook Trigger on the canvas; with two of them, the whole workflow runs.

Keep the URL secret

The token is the only credential, so anyone who holds the URL can start runs and spend your credits. For a workflow in an organization's workspace, the runs are paid by the workspace's budget: anyone you share the URL with can spend the class's or the team's credits.

Every automated run, whether from a webhook, a schedule or Telegram, first checks that the trigger's creator may still run the workflow. When they no longer can, because a grant was revoked, a membership was suspended or the workspace was archived, the automation stops. The workflow's run history then shows one failed entry with the code run_requires_authenticated_member.

Manage triggers through the API

Trigger nodes register themselves when the workflow is saved. Four routes manage them directly:

• GET /v1/workflows/<id>/triggers lists a workflow's triggers.
• PATCH /v1/workflow-triggers/<id> with { "isActive": false } pauses a trigger, and true resumes it. For a trigger that belongs to a node, the next save applies the node's own switch again, so use the node's switch for anything that should stick. A config you send is merged into the stored one: send only what changes. The trigger's link to its node and its run count are kept.
• POST /v1/workflows/<id>/sync-triggers registers the workflow's trigger nodes again from its saved version. The editor calls it after every save, and anyone with edit access may call it. It answers { "data": { "synced": …, "created": …, "updated": …, "removed": … } }.
• POST /v1/workflow-triggers creates a trigger that belongs to no node, so saving the workflow never changes or removes it. Creating one needs the same permission as running the workflow, because a trigger is a run that nobody attends.

Schedules

A Schedule Trigger runs a workflow on a timetable. A schedule is a list of rules, and the workflow runs whenever any rule matches the current minute.

Turn a schedule on

A Schedule Trigger node fires only while its data says "active": true, the node's switch. A node written through the API, the SDK or MCP without active is registered paused. The editor's switch and its Schedule button set the same field. A template export never carries it, so an imported schedule always starts paused.

Create a schedule by hand

{
  "workflowId": "8c2d7f1e-3a4b-4c5d-9e6f-7a8b9c0d1e2f",
  "type": "schedule",
  "config": {
    "rules": [
      { "kind": "days", "every": 1, "hour": 9, "minute": 0 },
      { "kind": "weeks", "every": 2, "weekdays": [1, 3], "hour": 18, "minute": 30 }
    ],
    "timezone": "Asia/Jerusalem"
  }
}

Send it with POST /v1/workflow-triggers. The same config shape is what a Schedule Trigger node stores.

• Every Nth day, week or month counts from a fixed start, and weeks start on Monday, so saving again never shifts the days a schedule runs.
• In a cron rule every field must match, both the day of the month and the day of the week, where some cron tools accept either one. 7 means Sunday, like 0.
• Values out of range answer 400, and so does a time zone the server cannot read.
• Older forms still work for triggers you create by hand: an interval such as 5m, 1h or 1d, or a cron string. A Schedule Trigger node saved with them is converted to rules.

How schedules fire

• The server checks the schedules once a minute and runs a workflow when one of its rules matches that minute.
• A minute never fires twice, even across a restart or a clock change. A minute the clock jumps over is skipped that day.
• If the previous run of the workflow is still going, that minute is skipped.
• A node that cannot run is parked, for example a cron rule with no expression or an unreadable time zone. Nothing is guessed: fix the node and save again.

Send results to your server

A Webhook Output node sends the result that reaches it, with the parameters you configure, to your URL as a POST request. Its parameters have the same types as the trigger's: text, imageUrl, videoUrl and audioUrl. Media values are URLs of files stored by Nodaro, which your server can download.

If your endpoint answers with an error, the node fails, and the error appears in the run's history. Use an https URL.

Send a key with the request

Many endpoints accept a request only with a key in a header. Save the header name and the key once as a credential in the web app, under Integrations › Credentials, and choose it in the node. The key never enters the workflow, an export or a template.

When you save a key, you choose who can use it:

Runs started with an API token or an OAuth token, by a webhook trigger, by a schedule created through the API, or from a published app are not your own, even though they run as you. For those runs, lock the credential: a plain one makes the node fail with a clear message instead of sending. A locked credential is sent only when the node's URL matches the address, a redirect to another address is not followed, and the key is never sent over plain http.

With a credential attached, the node does not keep or show your endpoint's response body, only its status code. Credentials are managed only in the web app: the credential routes answer 403 in_app_only to tokens. Publishing an app or sharing a workflow for others to run answers 409 credential_unbound until every credential it sends with, including inside sub-workflows, is locked to an address the node sends to.

No callbacks on API runs

A run you start through the API does not call a URL when it finishes. You have two ways to learn the outcome:

• Poll it. Follow the run with GET /v1/workflow-executions/:id, or a single node's job with GET /v1/jobs/:id/status. See Executions and Jobs.
• Let the workflow tell you. End the workflow with a Webhook Output node that posts the results to your server.