Custom Webhooks: Trigger an Agent From Any System, No Connector Required

Custom webhooks close that gap. You generate one signed URL inside Macha, paste it into whatever system can send an HTTP POST, and that system can now fire an AI agent the instant something happens — no connector, no integration to build, no polling. If a tool can send a webhook, it can trigger an agent.

This is a feature deep-dive: what a custom webhook trigger is, how to set one up, how the signing secret keeps it secure, how debounce and the raw-payload audit work, and the honest limits. Custom webhooks shipped in Macha's trigger system in March 2026 and have been hardened steadily since.

What a custom webhook trigger actually is

Macha agents run two ways. In chat, a person talks to them. Autonomously, a trigger fires them — and the agent works a ticket or an event with no human in the loop. Triggers are the autonomous half of the product, and the menu covers Zendesk ticket events, Freshdesk updates, Slack mentions, recurring schedules (cron), and the catch-all: custom webhooks.

A custom webhook trigger is the escape hatch. Where a Zendesk trigger says "fire when a ticket is created," a custom webhook says "fire when this URL receives a POST." Macha generates a unique endpoint with a signing secret; you hand that URL to any external system; that system POSTs a JSON payload when its event happens; Macha verifies the signature, hands the payload to your agent as context, and the agent runs. The headline from the changelog says it plainly: a unique webhook URL with a signing secret for any external service — no connector required, works with any system that sends HTTP webhooks.

The thing that makes this more than a glorified endpoint is what the agent does next. The triggering system doesn't need to know how to fix anything — it just rings the doorbell. The agent reads the payload, decides what's going on, and then acts through whatever tools you've given it: post a reply, update a ticket, look up an order in Shopify, refund in Stripe, message a channel in Slack, write a row in Airtable. The webhook is the trigger; the agent is the brain and the hands.

Setting one up

You add a trigger from an agent's Triggers tab, the same place you'd wire up a Zendesk or schedule trigger.

Pick Custom webhook and Macha generates two things:

1. A unique URL — the endpoint your external system will POST to. It's specific to this trigger on this agent, so you can give different systems different URLs and revoke one without touching the others.
2. A signing secret — a shared key used to verify that an incoming request genuinely came from the system you configured, and that nobody tampered with it in flight.

From there it's two paste operations. Copy the URL into your sending system's webhook settings. Copy the secret into the same system so it can sign its requests. Save. That's the whole setup — there's no OAuth dance, no API scopes to approve, no app to install on either side. The reason it works with anything is that it asks almost nothing of the sender: speak HTTP, send JSON, sign with the secret.

You can also describe the whole thing in plain language to Macha's AI agent builder — "fire this agent whenever our status page sends an incident webhook" — and it wires up the trigger, the URL, and the agent's tools for you, then shows them as clickable cards in the chat. The manual path above is what it's doing under the hood.

The signing secret: why it matters

A naked webhook URL is a liability. If the endpoint just accepts any POST, then anyone who learns the URL — a leaked log line, a misconfigured proxy, a curious ex-employee — can fire your agent at will. At best that burns credits. At worst it pushes a forged "refund this customer" event into a billing agent.

The signing secret is the fix, and it's the same pattern the serious webhook providers use. When your system sends a request, it computes an HMAC of the request body using the shared secret and includes that signature in a header — exactly how Stripe signs its webhooks (Stripe-Signature) and how Zendesk verifies webhook authenticity (X-Hub-Signature-256). Macha recomputes the HMAC on its side and only runs the agent if the signatures match. A forged request with the wrong secret — or a real request someone tampered with in transit — fails verification and never reaches the agent.

It's worth knowing this is a genuine differentiator, not table stakes. As one webhook-security teardown documents, several popular no-code automation tools — Webhooks by Zapier, Make, n8n — ship without built-in HMAC signature verification, which means teams either leave endpoints unauthenticated or hand-roll the check. Macha bakes the signed URL into the trigger from the start.

Debounce: don't let a chatty system DDoS your agent

Some systems are polite and send one clean webhook per event. Others are not — a CRM that emits five rapid updates as a record is saved, a monitoring tool that flaps. Fire an agent on every one of those and you've paid credits five times to process what was really one event.

Debounce handles it. You set a debounce interval on the trigger and Macha batches rapid-fire events inside that window before firing the agent once. It's a configurable knob, shown right on the trigger as a chip you can tune.

One nice detail that tells you the feature was actually used in anger: debounce is hidden by design on triggers where it makes no sense — cron schedules (which are clock-driven, not event-driven) and the per-org universal webhook (unkeyed). Debouncing a once-a-day schedule is meaningless, so Macha doesn't pretend to offer it there. For a keyed custom webhook fed by a chatty source, it's exactly the guardrail you want.

What the agent sees, and the audit trail

When the webhook fires, Macha hands the agent the payload as context — and it doesn't throw any of it away. Every autonomous conversation preserves the full raw webhook payload for audit and debugging. If an agent did something surprising, you can open that run and see the exact JSON that triggered it, byte for byte. That's the difference between "the agent went rogue" and "ah, the upstream system sent status: refunded when it meant status: refund_requested."

Macha also extracts the useful fields for display. Each connector's trigger definitions declare a contextSchema — which payload fields to pull out for the UI — so autonomous conversations show a connector icon, an event label, and a readable title in the sidebar and agent history instead of an opaque "Custom Webhook." For Zendesk and Freshdesk custom-webhook payloads, Macha now titles the conversation using the ticket_id and ticket_subject straight from the payload, so your history reads like real tickets rather than a wall of identical entries.

A few things you can wire up

Because the trigger asks so little of the sender, the use cases are basically "anything that can POST." A handful that come up often:

• Order events from Shopify Flow. Shopify Flow can send an HTTP request on order created or fulfillment failed; point it at a Macha webhook and an agent can proactively open a ticket, check the order, and draft an outreach — even though the event originated in a workflow tool, not a connector.
• Payment failures from a billing system. A subscription system POSTs on a failed renewal; a billing agent reads the payload, looks up the customer, and opens a triaged dunning ticket.
• Incidents from your monitoring stack. Datadog, PagerDuty, or a status page fires on an incident; an agent posts a structured summary to a Slack channel and files the internal ticket.
• Anything internal. A homegrown admin tool, a GitHub Action, a cron script — if it can curl a URL, it can fan out into an agent that takes real action across your connected tools.

The pattern is always the same: the external system knows that something happened; the agent figures out what to do about it. You're not building integration logic in the sending system — you're letting it ring a bell.

Lifecycle: pausing, trashing, and not breaking things

Webhook triggers behave sanely when you turn agents on and off, which matters because the sending system holds a URL you don't want to invalidate by accident.

• Pause/resume is a soft toggle. Toggling an agent off sets its triggers to inactive rather than deleting them, and the signing secret and config are preserved. Toggle it back on and the same trigger resumes — the external system's URL keeps working untouched.
• Trashing an agent pauses, doesn't destroy. A trashed agent's triggers are paused so they stop firing, but their webhook secrets and config are kept. Restore the agent and the trigger config comes back; you re-enable when ready.
• Explicit deletes do tear down fully. If you actually delete a trigger, it's gone — that's the deliberate way to retire a webhook for good.

The principle: nothing silently breaks the contract with the system on the other end of the URL unless you explicitly ask it to.

Watch-outs and when not to use it

Custom webhooks are powerful precisely because they let an outside system make your agent act. Keep that in mind:

• An autonomous agent acts without review. A webhook-fired agent runs end to end with no human gate, so be deliberate about which tools it holds. Macha shows activation confirmation modals and persistent advisory cards for high-impact tools (Add Public Reply, Update Ticket Status) for this reason — read them. Start an agent in a draft-only or read-only posture before you let it post publicly.
• Every fire costs credits. A webhook trigger that runs an agent costs whatever that agent run costs — credits are billed per AI action, and the per-message cost depends on the model (Macha's range runs 0.5–9 credits, with the default GPT-5.4 Mini at 1). A chatty source without debounce can run up a bill; set the interval.
• Use the signing secret. Always. An unsigned endpoint is an open door. Treat the secret like a password, rotate it if it leaks, and never paste it into client-side code.
• If a native connector exists, prefer it. Custom webhooks are the escape hatch for systems Macha doesn't natively support. If you're triggering on Zendesk or Freshdesk events, use the native Zendesk trigger — it carries richer, structured context out of the box. Reach for a custom webhook when there's no connector to reach for.
• It's a trigger, not a transform. A webhook starts an agent; it doesn't reshape your payload first. If your sending system emits something genuinely cryptic, give the agent clear instructions on how to read it (or fix the payload upstream).

How this compares to the alternatives

Webhook-triggered agents aren't unique to Macha — Relevance AI, Moveworks, MindStudio, and n8n all offer some flavor. What's worth comparing is the surrounding posture:

The distinction that matters for support teams: Macha isn't a general workflow runner that happens to call an LLM. The thing your webhook fires is an agent that sits on top of your existing helpdesk and can take real, governed actions across your connected commerce and knowledge tools. The webhook is just the most universal way to start it.

FAQ

What can send a webhook to Macha? Anything that can make an authenticated HTTP POST — Shopify Flow, Stripe, a monitoring tool, a CRM, a GitHub Action, a cron script, an internal app. No connector or native integration is required.

Do I need a connector for the system that's calling the webhook? No. That's the entire point — the custom webhook trigger exists for systems Macha doesn't have a native connector for. The agent's own tools (Shopify, Stripe, Slack, Zendesk, etc.) still come from connectors, but the trigger needs nothing.

How is the endpoint secured? Macha generates a signing secret with each webhook URL. The sender signs each request (HMAC over the body) and Macha verifies the signature before running the agent, so forged or tampered requests are rejected.

What happens if my system sends a burst of events? Set a debounce interval on the trigger and Macha batches rapid events inside that window before firing the agent once, so you don't pay to process the same event five times.

Does triggering an agent cost credits? Yes — a webhook fire runs the agent, and agent runs are billed per AI action in credits, priced by the model you choose. See the pricing page for current plans and credit allotments.

Will pausing the agent break the webhook? No. Pausing sets triggers inactive while preserving the secret and config; resuming brings the same trigger back so the external system's URL keeps working. Only an explicit delete tears the trigger down for good.

Try it

If you've been blocked by "Macha doesn't connect to that system," custom webhooks are the answer: one signed URL, and any HTTP sender can fire a real agent. Start a 7-day free trial, no credit card required, open an agent's Triggers tab, and generate your first webhook — or read the triggers documentation for the full setup walkthrough. More on building autonomous agents is on the blog.

Written by Abbas (Customer Support & AI, Macha) · Reviewed by Ankeet Guha (Co-founder & CTO) · Published 2026-06-24 · Last updated 2026-06-24.