Triggers & runs
A trigger is what starts a run. A run is a single execution of a Task or an agent. Triggers are the front door; runs are the record of what happened. Together they’re how Rightbrain moves from “a thing I built” to “a thing that operates.”
Triggers
Anything that can fire an event can start a run. A trigger targets a Task or an agent.
Webhook triggers
A webhook trigger has a public invoke endpoint:
Authentication is either hmac_sha256 (the caller signs the payload with a shared secret, sent in the configured signature header) or bearer_token (a bearer token). The auth method is fixed at creation — to switch methods, create a new trigger. Webhook triggers support optional payload mapping and idempotency, and you can rotate the secret or regenerate the endpoint.
HMAC authentication supports prefix, timestamp_kv, plain, and standard_webhooks signature formats. Standard Webhooks v1 uses a Base64-encoded HMAC over the message ID, timestamp, and raw body. Its default headers are webhook-signature, webhook-timestamp, and webhook-id, with a default timestamp tolerance of 300 seconds. The message ID also becomes the idempotency key when no payload path supplies one.
Configure idempotency_key_path when the sender may retry deliveries. Rightbrain remembers the extracted key for idempotency_ttl_seconds, preventing the same event from starting duplicate work during that window. Keep the same event ID when retrying.
For a task target, a duplicate returns 409 with error.code: "DUPLICATE_REQUEST" and error.original_task_run_id. For an agent target, a duplicate returns 202 with is_duplicate: true and the original event_id. These responses do not start another run. A bad signature returns 401 with error.code: "AUTH_FAILED".
Response behavior depends on the target. A task-targeted webhook runs synchronously and returns 200 with the run result in the body. An agent-targeted webhook returns 202 with the trigger event ID and processes the run in the background. Either way the invocation is recorded as a trigger event you can list and inspect.
Schedule and inbox triggers
- Schedule — a cron trigger that fires on a recurring timer.
- Gmail inbox — fires an agent (or Task) when mail arrives in a connected Gmail inbox, passing the message through as input.
Each trigger type records its own events, so you can see every firing and its outcome.
Runs
A run captures one execution end to end: inputs, tool calls, output, token counts, timing, and credits.
Statuses
Agent runs move through running → waiting_for_human (paused for an approval) → completed or failed. Task runs are request/response — they return the TaskRun directly.
Streaming (agents)
Agent runs stream Server-Sent Events so you can render progress live — incremental text, each tool call and its result, approval pauses, and a terminal done event. See Run agents via API for the full event reference and how to handle the stream.
Files in and out
Runs handle files through a runtime file registry. Agents accept uploaded input files (multipart or base64), pass them between tools within a single run, and track generated files with provenance (whether a file was an input or was generated, and by which Task). A paused run resumes with its file manager intact. Files are retrievable per run:
Observability and usage
Every run is recorded for observability. Run and event endpoints expose the execution source, failure metadata, and per-model telemetry. Runs are metered in credits, and token, credit, timing, and usage reports are available per Task, per agent, and project-wide. Sensitive audit events are recorded in the tamper-evident audit log.
Signed webhook example
This creates an agent webhook, maps the incoming message, and sends one event. Set RB_API_KEY, ORG_ID, PROJECT_ID, and AGENT_ID in your environment. The management API uses your API key; the public invoke endpoint uses the separate webhook secret returned at creation.
Create the webhook
Run
node webhook.mjswith Node.js 22+. The script creates an agent-targeted webhook, then signs and sends one event. The management request uses your API key; the response provides the webhook’s own secret and invoke URL.payload_mappingtakesmessagefrom the incoming JSON.idempotency_key_pathidentifies retries of the same event. Store the returnedauth_secretsecurely for future deliveries; do not log it.Sign the exact request bytes
Serialize the payload once, then compute its HMAC-SHA256 using the webhook secret. The configured
plainformat expects lowercase hex with no prefix.Re-serializing the JSON, or adding whitespace or a newline after signing, changes the signature. For retries, preserve the event ID and body. Running this whole script again creates a new trigger and event.
Send the event
Send the signed body to
endpoint_urlwith the signature inX-Signature. An agent webhook returns202with an event ID: this acknowledges receipt, not completed execution.The script prints the trigger and event IDs for inspection. A task-targeted webhook behaves differently: it returns the run result synchronously.
Inspect the execution
Set
TRIGGER_IDandEVENT_IDto the printed IDs, then poll the event. Inspectstatus,error_codeanderror_message. A completed agent event includestask_agent_run_idfor the agent run API.request_data.mapped_inputlets you check the mapping. Store request data according to your application’s privacy requirements. When testing is finished, disable the temporary trigger withPOST …/trigger/webhook/{trigger_id}and{ "status": "disabled" }.
With signature_format: "prefix", configure the matching signature_prefix (for example sha256=) and include it in the signature header. This example explicitly selects plain so the signing and verification rules match.