Send your first webhook

What you'll build

A workflow with a webhook trigger that fires every time you send an HTTP POST to its unique URL. By the end of this guide, you will have sent a real curl request and seen a run appear in your run history.

This guide skips authentication so you can see end-to-end success on the first try. After this works, follow the authentication guide to harden the trigger before pointing real providers at it.

Prerequisites

• A TaskJuice account with at least one workflow you can edit
• A terminal with curl installed (or any HTTP client like Postman, Insomnia, or HTTPie)
• About five minutes

You don't need a third-party provider, an API key, or any external service for this quickstart.

Step 1: Add a webhook trigger to your workflow

Open a workflow in the editor. The canvas shows a Start placeholder node where the trigger goes.

1. Click the Start node

   The Add node panel slides in from the right. Its header reads "Start by choosing a trigger to begin your workflow."

2. Switch to the System tab

   The Apps tab is selected by default. Click System to see generic triggers grouped by kind.

3. Click the Webhook trigger

   Find the Webhook group and click the trigger definition inside it.

The Start placeholder is replaced with a configured webhook trigger node, and the configuration panel opens on the right with your unique webhook URL already populated at the top.

Step 2: Copy your webhook URL

In the configuration panel, find the Webhook URL field. It looks like this:

https://api.taskjuice.ai/webhooks/550e8400-e29b-41d4-a716-446655440000

The token at the end is a 36-character UUID v4 unique to your trigger. Click the copy button next to the field to put the URL on your clipboard.

Step 3: Add a downstream action

A workflow needs at least one action node connected to the trigger so the run has somewhere to go. For this quickstart, any action will do.

1. Click the plus button below the trigger node

   The Add node panel reopens, this time with the Apps tab showing actions instead of triggers.

2. Pick any action you can run

   A simple choice is the Logger system node (under the System tab) — it has no external dependencies and prints the trigger payload to the run history. Or pick any app action that doesn't require a connection.

3. Connect the action to the trigger

   The two nodes connect automatically. Save the workflow.

Step 4: Publish the workflow

Draft workflows do not receive webhook events. You have to publish before the URL is live.

1. Click Publish

   The publish button is in the top-right of the workflow editor toolbar.

2. Confirm the publish dialog

   TaskJuice deploys the published version of your workflow. The webhook URL becomes live within a few seconds.

Step 5: Send a test request

Open a terminal and paste this command, replacing the URL with the one you copied in Step 2:

curl -i -X POST https://api.taskjuice.ai/webhooks/550e8400-e29b-41d4-a716-446655440000 \
  -H "Content-Type: application/json" \
  -d '{"event":"test","userId":"u_123","timestamp":"2026-04-06T14:32:00Z"}'

The -i flag tells curl to include the response headers. You should see something like this:

HTTP/1.1 200 OK
Content-Type: application/json
X-Request-Id: 7f8e9d0a-1b2c-3d4e-5f60-7a8b9c0d1e2f

{"received":true,"request_id":"7f8e9d0a-1b2c-3d4e-5f60-7a8b9c0d1e2f"}

Three things to notice in the response:

• 200 OK — TaskJuice accepted the request
• X-Request-Id header — a per-request UUID you can use to find this exact delivery in your run history
• request_id in the body — the same UUID, in case your tooling shows the body but not the headers

Step 6: Verify the run fired

Open your TaskJuice dashboard and navigate to the workflow's Runs tab.

You should see a new run with a timestamp matching the request you just sent. Click into the run to inspect:

• The trigger node's output is the JSON payload you sent
• The downstream action ran with $trigger populated from your payload
• Your workflow's $trigger.event resolves to "test", $trigger.userId to "u_123", and so on

If the run is missing, send the curl again and refresh. Webhook deliveries are usually visible within a second.

What could go wrong

• Confirm the workflow is published. Draft workflows do not receive events. Re-check the publish status in the editor.
• Confirm the URL is correct. Copy it again from the trigger panel — the token at the end is a long UUID and a single missing character makes it 404.
• Confirm your Content-Type header is set to application/json. Without it, the request may be rejected with 415 unsupported media type.
• Confirm you're using POST, not GET. Most webhook integrations use POST. The default trigger setup accepts both, but providers almost always send POST.
• Capture the request_id from the response and search for it in your run history. If the run is there, the issue is in the downstream action, not the trigger.

Next steps

You now have a working webhook trigger. Before pointing a real provider at it, you'll want to add authentication so unsigned requests are rejected.

• Authenticate your webhook — configure HMAC, bearer, or custom-header auth so only your provider can trigger the workflow
• Filter, deduplicate, and redact webhook events — recipes for the advanced settings panel
• Webhook trigger reference — every field, status code, and error message in one place