DocsDuties & Automation › Webhooks

Webhook Triggers

Every duty has its own secret webhook URL — POST to it from Zapier, Make, or your own application, and the duty starts a run, so any external tool can trigger a specialist the moment something happens.

How it works

Open a duty's editor and find its webhook URL. Paste it into whatever external system should be able to trigger the duty — an automation platform, a form handler, your own backend, or a script. A POST request to that URL starts a run of the duty.

  1. Open the duty and copy its webhook URL.
  2. Add it as an action or destination in your external tool (Zapier, Make, a script, your app's server).
  3. Trigger the external event — a new order, a form submission, a status change — and confirm the duty's run history shows the fire.

The URL includes a long secret token, so treat it like a password: anyone who has it can start the duty. Regenerate it from the duty's editor if you ever need to revoke access from a tool you disconnected.

What happens to the payload

Whatever data you send with the request is saved to the workspace inbox, where the specialist running the duty can read it as part of the task. A webhook can carry useful context — an order ID, a customer name, a status — into the run, rather than acting only as an on/off switch.

Rate limits

Each duty's webhook has its own rate limit, so a misconfigured integration sending rapid repeat requests can't run the duty in a tight loop or burn through your credits. Requests beyond the limit are held back rather than queued indefinitely.

If a trigger can't start the duty

If a webhook request arrives but can't start the duty — for example the duty is paused, or the account is out of duty slots — you get a notification rather than a silent failure, so you know to check the duty's state instead of wondering why nothing happened.

Good uses for a webhook trigger

Webhooks suit anything that already lives inside an automation platform or your own systems, where email isn't a natural fit:

  • An automation platform step that should hand off to a specialist for the parts that need judgment, not just data-moving.
  • Your own application posting an event — a new signup, a failed payment, a status change — the moment it happens.
  • Chaining CloudAxis into a larger pipeline, where an earlier tool's output becomes the payload for a duty's run.

Webhooks vs. email triggers

Use a webhook when the trigger already comes from software you control or from a platform like Zapier or Make. Use an email trigger instead when the signal only ever arrives as an email, since there's no need to route it through another tool first. A duty can have both at once, alongside its regular schedule.

Tip: pair a webhook with a light recurring schedule on the same duty as a backstop, the same way you would with an email trigger — external services occasionally fail to deliver a request.