Receive webhooks without exposing your systems

How it works

Webhook sources send events to a URL we give you. We ingest and store them in a durable queue. Your agent, worker, or workflow pulls events when it runs, processes them, and reports back. Receiving is decoupled from processing—you don't need a listening server.

Provider → our relay (we store) → you pull → you process → you report back.

Everything in one dashboard

Monitor volume, track event status, inspect payloads, and manage sources—all from a single pane of glass.

Pull from the command line

The CLI fetches events, lets you process them in any script or language, and reports back. No HTTP server, no framework—just pull, process, done.

# Pull new events (long-poll waits up to 25s for new ones)
$ agentwebhook-cli pull --source=src_XXX --wait=25

# Events arrive as JSON — pipe into jq, Python, anything
{"events":[{"event_id":"evt_abc","payload":{...}}], "count":1}

# Done processing? Report back.
$ agentwebhook-cli ack --event=evt_abc
Acknowledged 1 event

# Need more time? Extend the lease.
$ agentwebhook-cli heartbeat --event=evt_def --extend=120

# Or watch continuously — events stream as they arrive
$ agentwebhook-cli watch --source=src_XXX

Why a pull relay

Most webhook tools are push-first: they need a public URL, a running server, or a tunnel. AgentWebhook is pull-native. Your side only makes outbound connections. That means:

Events sit in our queue until you fetch them—encrypted in transit and at rest, with retention under your control. Works inside restricted enterprise networks, on laptops, and on edge devices. That's zero-trust webhook ingestion.

Works with the tools you use

Reliable by design

Every event goes through a managed lifecycle: ingest, queue, lease, process, confirm. Failed events retry automatically. Nothing falls through the cracks.

Common questions