Dashboard

Run, schedule and trigger

Pass inputs and start a workflow manually, on a schedule, from a webhook or from an event.

Before you begin

You need owner or dashboard editor access to run workflows or change triggers. Declare and save your workflow inputs first.

Run manually

  1. Open the workflow's Pipeline tab.
  2. Choose Run.
  3. Fill in the declared inputs and submit the form.
  4. Open Runs to inspect the result.

Without inputs, Run starts immediately. Required or invalid values block submission. Runs continue after you close the page.

Add a schedule

  1. Choose Add trigger, then Schedule.
  2. Set the recurrence, time and timezone.
  3. Under Data, assign a Fixed value to every required input.
  4. Save the trigger.

Schedules support daily runs, selected weekdays, selected month days and fixed minute or hour intervals. A month day beyond the month's end runs on its last day. The workflow shows the next run time.

Each trigger has its own Enabled setting. Disabling the workflow pauses all schedules; enabling it resumes enabled schedules from their next occurrence. Several triggers can start the same pipeline with different input assignments. Trigger changes save separately from inputs and steps; use Save trigger when editing one.

Every trigger must supply a value for each required input. Required inputs in the trigger drawer shows what is missing, and saving waits until each has a value. A new webhook is the exception until its first delivery arrives.

Connect a webhook

  1. Choose Add trigger, then Webhook.
  2. Choose Create webhook. Its URL appears under Address.
  3. Copy the URL and choose Reveal to obtain the secret.
  4. Send a POST request with the secret in the X-Botchi-Webhook-Secret header, or use Paste an example.
  5. Under Received data, choose the input each field feeds. New input creates an input from a field.
  6. Choose Save trigger.

Advanced holds a request example. An optional Idempotency-Key header prevents retries with the same key from starting another run. The Assistant and MCP can return the URL, but never receive the secret.

Botchi answers 202 once it has stored a request, and the run is queued right after. A retry with the same Idempotency-Key and body answers 200 and starts nothing; the same key with a different body is refused with 409. Keys are remembered for at least 7 days. Requests that started nothing or kept failing appear in the webhook drawer with their reason; editors can choose Retry on a failed one.

Signed requests

If the sender supports Standard Webhooks, choose Standard Webhooks signature under Authentication. The sender then signs each request with the secret instead of sending it, in the webhook-id, webhook-timestamp and webhook-signature headers. A missing or wrong signature, or a timestamp more than 5 minutes away, is refused with 401. webhook-id replaces Idempotency-Key: the same id and body answer 200, the same id with a different body 409. Switching the mode creates a new secret.

Watch out — Rotate invalidates the old secret immediately. Update the sender before relying on further deliveries. Only editors and owners can reveal or rotate secrets.

Listen for an event

  1. Activate the required account connection under Connections.
  2. Choose Add trigger, then an event: WhatsApp · Message received, Slack · Mention or direct message, Slack · /botchi command or Facebook · New lead.
  3. Under Connection, choose the connection the trigger listens to. WhatsApp and Slack can also listen to all their connections; Facebook · New lead always names one, such as one client of an agency.
  4. Under Received data, choose the input each event field feeds, or create one with New input.
  5. Give other required inputs a fixed value under Inputs without data.
  6. Save the trigger.
  7. Use Variable → Inputs in your steps to consume those values.

A trigger saves only when its source is ready: the webhook verified and, for the chosen connection, everything its connector page lists. Facebook · New lead also needs the Pages selected and subscribed; see social channels. Its fields include the form answers, such as Email. One workflow can have the same event once per connection, for example one trigger per client.

For a WhatsApp reply, declare a recipient input and assign it to the event’s Reply address. Slack replies use Reply channel and, where available, Thread.

Filter sender values with a Condition: put matching actions on the true lane and leave the false lane empty. Every active listener receives the event; several replying workflows send several replies. With no listener, WhatsApp stays silent; Slack gives a private notice at most once per connection and channel each hour.

Test and inspect deliveries

  1. Save the trigger's input assignments.
  2. Choose Try with the sample in the webhook or event drawer.
  3. Inspect Recent deliveries and the run trace.

Watch out — A sample test executes real steps and spends Sparks. It can send messages or change data. Send a fresh source delivery if the sample cannot be replayed.

Recent deliveries lists the latest 50 deliveries, outcomes and drop reasons. Missing required inputs prevent a run. Delivery data is kept for 30 days. Viewers see arrival times and assigned field names; only managers see values. Original data appears under Advanced for webhook and event runs.

External deliveries queue and run one at a time. Automatic runs act as the workflow's last editor and use shared account Sparks. See failures and concurrency.