Skip to main content
For a step-by-step walkthrough with screenshots, see Start a Workflow from Another App with a Webhook.
Most SaaS tools support incoming and outgoing webhooks. Combined with Hiveku Workflows, that’s a universal adapter — you can integrate with almost anything, even services not in our native integration list.
If your target service is popular (Stripe, HubSpot, Slack), check for a native integration first. Webhooks are the fallback for everything else.

​
Two Directions

Inbound

External service sends data TO Hiveku

Outbound

Hiveku sends data TO external service

​
Common Use Cases

  • Stripe → Hiveku — payment events create CRM records, trigger onboarding emails
  • Typeform / ConvertKit / Calendly → Hiveku — form submissions, newsletter signups, booking confirmations
  • Hiveku → Discord / Telegram — community pings when internal events fire
  • Hiveku → your own internal API — sync data into legacy systems you control

​
Inbound Webhook Pattern

External service fires an event, Hiveku receives and processes it.
1

Create a workflow with a Webhook trigger

Workflows > New Workflow. Add Webhook trigger. Copy the generated URL — this is your endpoint.
2

Register the URL with the external service

In the external service’s settings, find the Webhooks section. Paste your Hiveku webhook URL as the endpoint.
3

Choose events to subscribe to

Most services let you pick specific event types — charge.succeeded, form.submitted, booking.created. Only subscribe to events you’ll actually process; noise slows down debugging.
4

Save — external service sends a test event

Most services fire a test payload when you register a new webhook, to verify the URL works. Hiveku’s webhook trigger responds 200 on any valid POST, so the test should pass.
5

Handle the event

Add downstream actions in your workflow to process the event: send email, update database, call another API.
6

Inspect the first real payload

Open Workflows > your workflow > Runs and check the trigger data from the first real event. Use the actual field names there when building downstream steps.

​
Outbound Webhook Pattern

Hiveku fires the event, external service receives.
1

Get the target URL

From the receiving service’s docs. Usually labeled “webhook URL” or “incoming webhook endpoint”.
2

Add an HTTP Request action

In your Hiveku workflow, click + Add Action > HTTP Request:
  • Method: usually POST (some services require PUT — check docs)
  • URL: the target URL
  • Headers:
  • Body: JSON matching the receiving API’s spec. In a workflow started by a Webhook trigger, the fields that were posted to it are under trigger.output.payload:
3

Test with the service's sandbox

Many services offer a test mode or sandbox endpoint. Use that before flipping to production URL.

​
Securing Inbound Webhooks

Public webhook endpoints are open to the internet. Without verification, anyone who discovers the URL can forge events.
Treat webhook URLs like API keys. Don’t commit them to public repos or share in screenshots.
HMAC signature verification is the gold standard. Most reputable services (Stripe, GitHub, Shopify) sign outgoing webhook payloads with a shared secret. Verify the signature before processing:
  1. The service sends the signature in a header (e.g., Stripe-Signature, X-Hub-Signature-256).
  2. Your workflow reads the raw request body and the header.
  3. Compute HMAC-SHA256(body, shared_secret) and compare to the header value.
  4. Reject requests with mismatched signatures.
Hiveku’s Webhook trigger keeps the parsed body (trigger.output.payload) and the request headers (trigger.output.headers), but not the raw bytes of the body. A signature computed over the raw body therefore cannot be reproduced exactly inside a workflow: re-serializing the parsed JSON changes whitespace and key order. When the sending service supports it, protect the URL in the Webhook trigger’s Authentication section instead (click Apply authentication), so a request without the right credential is refused before any step runs. URL rotation is the fallback when signature verification isn’t available. If a webhook URL leaks, delete the trigger and create a new one — all old URLs stop working immediately.

​
Handling Failures

Webhooks are fire-and-forget. Neither side is guaranteed to process every message without error.
  • External services retry on 5xx responses. Return 200 as fast as possible — within 3 seconds is the informal standard — then process async if needed. For long-running work, drop the event into a queue and acknowledge immediately.
  • For outgoing webhooks, Hiveku retries with exponential backoff when the receiver returns 5xx or times out. Check the workflow’s Runs tab for retry attempts.
  • Turn on failure alerts so broken integrations don’t silently drop events. Switch on Email admins when a triggered run fails in the gear menu (Workflow Options, top right of the workflow editor): the account’s owners and admins get one email per incident when a run fails. A failed webhook run never pauses its workflow, so without alerts a broken step fails quietly on every delivery.
Most complex integrations can be built with 2-3 webhook-connected workflows. If you find yourself chaining six or seven, consider opening a native integration request — the engineering team can often prioritize common patterns.

​
Testing Webhooks Locally

When you’re debugging payload formats or signature verification:
  • webhook.site — free tool that catches any POST and shows the full payload. Paste your workflow URL into the external service temporarily, fire an event, and inspect what’s actually sent.
  • ngrok — tunnels your local development server to a public URL. Useful when building custom webhook handlers outside of Hiveku.
  • Test the workflow in the editor — click Test Run and give it a sample request body. It is a dry run: each step shows what it would have sent, and nothing is sent, so you can iterate on downstream actions without waiting for real events.
Always test in staging before enabling on production. A misconfigured outbound webhook that blasts real customer data to the wrong URL is a rough day.

​
Verify It Worked

Fire a real event from the external service. Confirm:
  1. The Hiveku workflow’s Runs tab shows the event with the expected payload
  2. Downstream actions completed without errors
  3. For outbound webhooks, the receiving service logs show the event arrived
  4. Retries and failures (if any) are being reported to your chosen alert channel

​
Troubleshooting

Check the obvious causes first: URL typo, external service expecting a different HTTP method (some want POST, others PUT), workflow not enabled. If the external service has a “recent deliveries” log, it’ll tell you whether the request was attempted at all.
An HMAC has to be computed over the raw request body, not the parsed JSON: parsing and re-serializing changes whitespace and key order, which breaks the signature. A Hiveku workflow sees only the parsed body (trigger.output.payload) and the headers, not the raw bytes, so it cannot check such a signature exactly; use the Webhook trigger’s Authentication section to protect the URL instead. Also check the secret — leading/trailing whitespace is a classic cause of silent mismatches.
External service docs sometimes lag behind actual behavior. Log the first real payload (via webhook.site or a Hiveku Code step that writes to a table) and build against that. Don’t trust the docs as the source of truth for field names.
Authentication header is wrong. Check the external service’s API docs for the exact format — some want Authorization: Bearer <key>, others want X-API-Key: <key>, others use Basic Auth. Copy the example from their curl snippet exactly.
The receiver is limiting how many requests/sec you can send. Add a Delay action between requests, batch events into a single call, or contact the service for a higher rate limit. If it’s inbound, acknowledge fast and process async.

​
What’s Next?

Workflows Basics

Triggers, actions, and run history explained

Connect Zapier

Use Zapier as a universal bridge to 6,000+ apps