Two integration patterns. Whether your agent pulls events or receives them in real time, the infrastructure is the same.
Hookwing works the same way underneath — your agent polls or receives push events. Pick the integration style that fits your workflow.
Your agent creates endpoints, ingests events, and monitors delivery — all through the REST API. No manual intervention needed.
# 1. Sign up (agent creates account)
curl -X POST https://api.hookwing.com/v1/auth/signup \
-H "Content-Type: application/json" \
-d '{"email": "[email protected]"}'
# 2. Create endpoint
curl -X POST https://api.hookwing.com/v1/endpoints \
-H "Authorization: Bearer $HW_KEY" \
-d '{"url": "https://your-agent.com/webhook", "name": "agent-inbox"}'
# 3. Poll for events
curl https://api.hookwing.com/v1/endpoints/ep_xxx/events \
-H "Authorization: Bearer $HW_KEY"Click through the wizard in your browser. Create endpoints, configure sources, and monitor delivery — all without writing code.
These are actual commands and code you can use. No hypotheticals.
Receive payment events from Stripe. Verify signatures automatically. Trigger actions when payments succeed or fail.
# Create endpoint for Stripe webhooks
curl -X POST https://api.hookwing.com/v1/endpoints \
-H "Authorization: Bearer $HW_KEY" \
-d '{"url":"https://your-app.com/stripe","name":"stripe-payments","eventTypes":["payment_intent.succeeded","charge.failed"]}'Configure Stripe to send to this URL. Hookwing verifies the signature before delivery.
Fan-out GitHub events to Slack, email, or your monitoring pipeline. One webhook source, multiple destinations.
# Fan-out GitHub events to multiple services
curl -X POST https://api.hookwing.com/v1/endpoints \
-H "Authorization: Bearer $HW_KEY" \
-d '{"url":"https://slack.com/webhook","name":"github-to-slack","eventTypes":["push","pull_request"]}'Each event type can route to different endpoints. Set up transforms to format for each destination.
Your Python agent receives webhooks directly. Hookwing handles signature verification so you get clean, trusted payloads.
# Python agent listening for webhooks
from hookwing import Webhook
wh = Webhook("whsec_your_secret")
event = wh.verify(payload, headers)
# Process the verified event
agent.process(event.payload)The SDK handles signature verification for you. Works with any webhook source.
A single webhook event can trigger multiple downstream actions. Each destination retries independently.
Each destination has its own retry policy. If Slack is down but email works, they retry independently.
Hookwing sits between the services sending events and the agents or systems consuming them. There are two ways to integrate. Pick the one that fits your architecture.
Services send webhooks to Hookwing. Your agent polls when it's ready, even if it was offline when the event fired. Hookwing holds the events.
Stripe / GitHub / Slack → Hookwing verifies + stores → Agent polls GET /events?since=<timestamp>
Hookwing receives the webhook, verifies the signature, and forwards it to your endpoint. If your agent is temporarily down, it buffers and retries with exponential backoff.
Source service → Hookwing verifies + buffers → Your endpoint → Retry if needed
These aren't hypotheticals. They're the patterns teams and agents are running today.
A PR opens, GitHub fires a webhook to Hookwing, your coding agent gets it and posts a review. No polling loop. No delayed response.
Stripe fires payment_intent.succeeded to Hookwing. Your agent provisions the account, sends the welcome email, updates the CRM. If the agent is mid-restart when the payment lands, Hookwing holds the event until it's back.
One incoming event routes to your CRM agent, email agent, and analytics pipeline. Each destination retries independently. You see delivery status per leg.
Agent A finishes a task and POSTs the result to a Hookwing endpoint. Agent B polls for it when ready. No direct networking between agents, no shared message queue to manage. OpenClaw uses this pattern internally to pass work between specialized agents.
Your monitoring tool sends a webhook to Hookwing. Your agent receives it and runs a diagnostic with no polling delay and no manual triage. Standard pattern for teams running unattended agent pipelines.
If you're evaluating whether to use Hookwing or roll your own, here's an honest breakdown of what each actually requires.
| DIY / AWS | Hookwing | |
|---|---|---|
| Setup | IAM roles, Lambda config, SQS queues, retry logic | One POST to create an endpoint |
| Signature verification | Write per-provider (Stripe, GitHub, etc.) | Built in |
| Retry logic | Write, test, maintain | Automatic. Configurable. |
| Event history + replay | Build a log store or go without | Full history, queryable, replayable |
| Debugging | CloudWatch logs at best | Payload inspector in dashboard |
| Free tier | Nothing meaningful | 25,000 events/month, no credit card |
| Agent access | Varies, no standard | REST API, API-key auth, pull or push |
| Cloud account required | Yes | No |
The tradeoff is setup time and maintenance overhead, not capability. If you already have the infrastructure, you may not need us. If you're starting from scratch, we're faster.
Or create a free account: 25,000 events/month, no credit card.
Agents can provision programmatically via /v1/auth/signup.