Skip to main content
Many services announce what happens on their side by calling a URL you give them: a payment succeeded, a pull request was merged, a form was sent. A webhook is that URL. Each call to it becomes an event in your project, and every workflow listening for that event starts a run with the call’s body as its payload. You don’t write or host any code to receive the call. Nelkap receives it.

Create a webhook

  1. Go to Webhooks and create one in your project.
  2. Choose the event it emits, like checkout.completed.
  3. Copy its URL, and paste it in the other service’s webhook settings.
The URL looks like https://api.nelkap.com/webhooks/<secret>. Then register a workflow that listens for the event:
The payload is the call’s JSON body, exactly as the service sent it. Type it after the service’s own documentation.

What the webhook accepts

Each call is a POST with a JSON body. Nelkap answers: A webhook emits an event with no tags and no wakeOn key, so it starts runs but doesn’t wake waiting ones. To wake a run from another service’s call, receive the call in your app and emit the event yourself.

Keep the URL private

The secret in the URL is what proves a call is meant for your project, so treat the URL like a password:
  • If it leaks, rotate the webhook’s secret. The old URL stops working at once, so paste the new one in the other service right after.
  • To accept calls only from the service’s servers, set the webhook’s allowed IPs: up to 20 addresses or ranges, like 203.0.113.7 or 203.0.113.0/24, in IPv4 or IPv6.
Nelkap doesn’t check the signatures some services add to their calls. When you need that check, receive the webhook in a route of your app, check the signature there, and emit the event with emit. The order fulfillment example does this for Stripe.

Turn a webhook off

Disable a webhook to stop it for a while without losing its URL. While it’s disabled, its calls get a 404 and emit nothing. Enable it again, and the same URL works as before.

Follow your webhooks

Each webhook shows its event, its project, its URL, its allowed IPs, its status, and how many events it has emitted. The events themselves are listed with every other event, with the runs each one started. See Events.

Who can do what

Everyone in the workspace can see webhooks. Creating, changing, and disabling them takes the Member role or above, and rotating a webhook’s secret the Admin role. See Members and roles. Your plan sets how many webhooks your workspace can have. See Limits.