Webhook Actions

Send outbound HTTP requests to external APIs and services as a step within a workflow. Configure URL, method, headers, and body — with full support for dynamic field mapping from upstream nodes.

Action Node Outbound HTTP No Connection Required Dynamic Field Mapping

What is the Webhook node?

The Webhook node is an action node that sends outbound HTTP requests to external APIs or services as a step within a workflow. It allows you to configure a URL, HTTP method, headers, and body — with full support for dynamic field mapping from upstream nodes.

Unlike regular app nodes, the Webhook action requires no connection. You must test the request before saving — the test response is what generates the output schema that downstream nodes can reference.

What Webhook lets you do

Send GET, POST, PUT, PATCH, DELETE requests to any external endpoint
Pass dynamic values from upstream nodes into the URL, headers, and body
Add custom authentication — Basic, Bearer token, API Key, and more
Use the HTTP response as structured output for downstream nodes
Integrate with any service that exposes an HTTP API — no pre-built connector needed

Prerequisites

What you'll need before adding a Webhook

An active Konnectify account with an existing konnector.
A konnector with at least one trigger configured.
The target API's endpoint URL and the HTTP method it expects.
Any required headers (e.g., Authorization, Content-Type) or auth credentials for the external service.
Sample values for any dynamic field references — needed to run the test before saving.

Understanding Webhook Logic

Understanding how the configuration stages, field mapping, test execution, and output schema work together is key to using the Webhook node effectively.

Configuration stages

Stage	What happens
1 — Base Config	Select the Webhook app and choose the HTTP method event (GET Request, POST Request, etc.)
2 — Field Mapping	Configure URL, headers, body, auth, and timeout using the field mapper. Dynamic values from upstream nodes are supported.
3 — Test	Run the actual HTTP request with sample values. On success, the response JSON is used to generate the output schema.
4 — Save	Continue saves field mappings, output schema, and test data to the node. Output fields are now available for downstream mapping.

Input fields available

Field	Required	Notes
URL	Yes	The target HTTP endpoint. Supports dynamic field references (e.g., `https://api.example.com/users/{{1:userId}}`)
Method	Yes	GET, POST, PUT, PATCH, DELETE, etc.
Headers	No	Key-value pairs for custom HTTP headers. Dynamic values supported.
Body	No	Only visible for POST, PUT, PATCH. Hidden for GET and other methods that don't support a body.
Auth Type	No	Basic, Bearer, API Key, etc. Additional fields appear based on selection.
Timeout	No	Request timeout in seconds. Server-side limit enforced.

How the output schema is generated

After a successful test, the response JSON structure is analysed.
Each top-level property becomes a field available for downstream mapping.
Field types are inferred — string, number, boolean, array, object.
The schema is persisted on the node (outputSchema and testData fields).
The schema cannot be manually defined — it is always derived from the test response.
If the output schema changes from a previous save, downstream nodes are validated and may be marked as unconfigured.

How Webhook differs from regular app nodes

Aspect	Regular App Node	Webhook Action
Requires connection	Yes	No
Must test before save	No (optional)	Yes (required)
Output schema source	Pre-defined by the API	Inferred from test HTTP response
Connection selector shown	Yes	No
Input field types	Mostly select, multi-select	Text, URL, select, key-value, number, textarea

Key Components

URL & Method REQUIRED

The URL is the target HTTP endpoint and supports dynamic field references from upstream nodes (e.g., https://api.example.com/users/{{1:userId}}). The Method determines the HTTP verb — GET, POST, PUT, PATCH, DELETE, etc. Changing the method after a successful test clears the test results and requires re-testing.

Headers OPTIONAL

Key-value pairs for custom HTTP headers. Common uses include Content-Type: application/json, Authorization: Bearer {{1:token}}, or custom API keys. Both keys and values support dynamic field references from upstream nodes.

Body CONDITIONAL

The request body — only visible when the method is POST, PUT, or PATCH. Hidden for GET and other methods that don't support a body. Accepts key-value pairs or textarea format. Supports dynamic field references.

Auth Type OPTIONAL

Authentication method for the request. Options include Basic, Bearer token, and API Key. Additional credential fields appear based on the selected auth type. Auth values support dynamic field references from upstream nodes.

Timeout OPTIONAL

Request timeout in seconds. Controls how long the Webhook waits for a response before failing. Subject to a server-side timeout limit regardless of the configured value.

Test Execution REQUIRED BEFORE SAVE

The Test Data button sends the actual HTTP request to the configured URL. This is mandatory — the Continue button remains disabled until a test succeeds.

If field values contain dynamic references (e.g., {{1:userId}}), a Test Data Dialog prompts for sample values before executing.
Success: Shows the response body in an expandable tree view with status details. Output schema is automatically inferred.
Error: Shows the error message. Continue remains disabled.
All required visible fields must be mapped before the Test Data button becomes active.

Output Schema AUTO-GENERATED

The output schema is inferred from the test response JSON. Each top-level key becomes a downstream-referenceable field. Cannot be manually defined. If the response structure changes between test and production, downstream mappings may break and require reconfiguration.

When to Use

Use a Webhook node when you need to call an external HTTP API that doesn't have a dedicated Konnectify connector — or when you need full control over the raw request.

✓ Good fits

Calling an internal or custom API not in the app directory
Sending data to a third-party service via REST
Triggering a webhook in another platform
Posting to a custom notification or logging endpoint
Fetching data from an API and passing it downstream

✗ Not the right tool

Receiving inbound webhooks (use a Webhook Trigger instead)
Services with a dedicated connector (use the App node for better UX)
APIs requiring OAuth flows (use an App node with connection setup)

Step-by-step Guide

Add a Webhook node

In the workflow canvas, click the + button on the node after which you want the request.
Open the app selector and choose Webhook.
Select the event — e.g., POST Request or GET Request.
The sidebar opens to the field mapping configuration. No connection setup is needed.

Configure the URL

Enter the target endpoint in the URL field.
To include dynamic values, use the field mapper to insert references from upstream nodes (e.g., https://api.example.com/items/{{1:itemId}}).

Add headers (optional)

In the Headers section, add key-value rows for any required headers.
Common headers: Content-Type: application/json, Authorization: Bearer {{1:token}}.
Both keys and values support dynamic field references.

Configure the body (POST / PUT / PATCH only)

The Body field only appears for POST, PUT, and PATCH methods.
Add the fields and values your API expects in the request body.
Use dynamic references to pass values from upstream nodes.

Note: If you change the method after configuring the body (e.g., POST → GET), the body field is hidden and the test results are cleared. You must re-test with the new configuration.

Set auth and timeout (optional)

Select an Auth Type if the endpoint requires authentication.
Enter the required credentials — these can be dynamic references from upstream nodes.
Optionally set a Timeout in seconds.

Test the request

Click the Test Data button in the sidebar footer.
If any fields contain dynamic references, the Test Data Dialog opens — enter sample values and submit.
The system sends the actual HTTP request to your configured URL.
On success: the response is shown in an expandable tree view and the output schema is generated.
On error: review the error message, fix the configuration, and re-test.

Important: The request is sent live to the real URL during testing. Use a test/staging endpoint if you don't want to affect production data.

Save and connect downstream nodes

Once the test succeeds, click Continue to save field mappings, output schema, and test data to the node.
Add the next node in your workflow and use the field mapper to reference fields from the Webhook's response output.

Things to Know

Edge cases and platform behaviours worth knowing before you build.

Edge cases

Scenario	Behavior
Placeholder values in fields	Test Data Dialog prompts for sample values before executing
Method change after test	Test results cleared; output schema reset; must re-test before saving
Required fields not mapped	Test Data button disabled until all required visible fields are mapped
Test returns empty response	Output schema may be empty; downstream nodes won't have fields to reference
Test returns inconsistent structure	Schema is best-effort inferred; may not perfectly match all future responses
Broken field references	If an upstream node changes, webhook field references may break — detected and flagged visually
Body field with GET method	Body field is hidden; only visible for POST, PUT, PATCH
Output schema changed after re-test	Downstream nodes are validated and may be marked as unconfigured if mapped fields no longer exist
Read-only mode	All fields disabled; Test Data button hidden; Continue button disabled

Restrictions summary

Restriction	Detail
Test required before save	Must execute a successful test to generate output schema; Continue is disabled until tested
No connection needed	Webhook actions are standalone — no OAuth or credential connection required
Output schema is inferred	Cannot manually define schema; always derived from test response
Conditional fields	Body, auth, and other fields may be shown/hidden based on method selection
All required fields must be mapped	Cannot test until all visible required fields have values
Placeholder resolution	Field references in URL/headers/body must be resolved with sample values during testing
Timeout limits	Server-side timeout enforcement on test execution
Field references	Can reference fields from upstream nodes only; broken references flagged visually
Schema persistence	Output schema stored on node; if response structure changes between test and production, downstream mappings may break

Live requests during test: Clicking Test Data sends a real HTTP request to the configured URL. If you're testing against a production endpoint, use caution — the request will execute and may create, update, or delete real data.

Examples

POST a new contact to an internal CRM API

CRM integration · POST Request · Dynamic body fields

POST

A form submission triggers the workflow. You want to create a new contact in your internal CRM by calling its REST API with the form data as the request body.

Webhook configuration

URLhttps://crm.internal.com/api/contacts

MethodPOST

HeadersContent-Type: application/json

Body

name → {{1:fullName}}

email → {{1:email}}

company → {{1:company}}

✓ On success — API returns the created contact object. Output schema includes id, name, createdAt — available to downstream nodes.

✗ On error — Error message displayed. Continue remains disabled. Fix the configuration and re-test.

GET user details from an upstream ID

Data enrichment · GET Request · Dynamic URL parameter

GET

Your trigger returns a userId. You want to enrich the data by fetching the full user profile from an external service before passing it downstream.

Webhook configuration

URLhttps://api.example.com/users/{{1:userId}}

MethodGET

AuthBearer token → {{env:API_TOKEN}}

During test, the Test Data Dialog asks for a sample userId value to substitute into the URL before sending.

✓ On success — Returns full user profile. Output schema includes name, email, plan, etc. Available to downstream nodes.

Trigger a build pipeline via webhook

DevOps · POST Request · API key auth

CI/CD

When a specific Jira ticket moves to "Ready for Release", you want to trigger a deployment pipeline in your CI/CD system by calling its webhook endpoint.

Webhook configuration

URLhttps://ci.company.com/pipelines/deploy/trigger

MethodPOST

HeadersX-API-Key: {{env:CI_API_KEY}}

Body

branch → {{1:branchName}}

env → production

✓ On success — CI returns a build ID and status. These become available as output fields for a downstream Slack notification.

Update a record and use the response downstream

Data sync · PUT Request · Response used in next step

PUT

Update a customer record in a third-party system, then use the updatedAt timestamp from the response in a downstream audit log entry.

Webhook → Downstream flow

PUT /customers/{{id}} → Code Block → Log entry

The Code Block reads {{2:updatedAt}} from the Webhook response to format the audit log entry.

✓ Result — Webhook output fields (id, updatedAt, status) are available to every downstream node just like any other app node output.

Workflow Diagrams

Pattern 1 — Simple outbound call

Trigger → Webhook → Next Action

Trigger fires, Webhook sends the request, response fields are available to the next action.

Pattern 2 — Enrich then act

Trigger → Webhook (GET) → Filter → App Action

GET request fetches enriched data. Filter gates the action on a field from the response (e.g., only proceed if status = active).

Pattern 3 — Transform then POST

Trigger → Code Block → Webhook (POST) → Slack

Code Block transforms the trigger data into the shape the target API expects, then Webhook POSTs it. Slack notification uses the response ID.

Pattern 4 — Webhook inside a Repeater

Repeater loop (per item)

Webhook (POST) → Update Variable

Webhook fires once per array item inside a Repeater. Use Update Variable to accumulate response data (e.g., collect created IDs) across iterations.

Testing Your Webhook

Testing is mandatory before saving. A successful test generates the output schema and enables the Continue button.

Map all required fields first

The Test Data button is only active once all required visible fields — URL and Method at minimum — have values. Check for any red validation indicators before clicking Test Data.

Provide sample values for dynamic references

If any field contains a placeholder like {{1:userId}}, the Test Data Dialog opens. Enter realistic sample values that the target API will accept — not just dummy strings.

Review the response

On success, the response body is shown in an expandable tree view. Verify the structure is what you expect — these fields will become your output schema. If the response is empty, downstream nodes won't have fields to map.

Re-test if you change the method

Changing the HTTP method after a successful test clears the results and requires re-testing. The previous output schema is reset to prevent stale field references in downstream nodes.

Save with Continue

Once the test succeeds, click Continue to save the configuration, output schema, and test data. The output schema is now available for downstream nodes in the field mapper.

Good practice: Use a staging or sandbox endpoint during testing. The test sends a real HTTP request — using production endpoints may create real records, trigger notifications, or consume API quota.

Frequently Asked Questions

Configuration & Setup

Do I need to set up a connection for the Webhook node?+

No. The Webhook node is standalone — it requires no OAuth connection or credential setup in Konnectify. Authentication details (API keys, Bearer tokens, etc.) are configured directly in the request headers or Auth Type field.

Why is the body field not showing up?+

The body field is only visible for POST, PUT, and PATCH methods. For GET, DELETE, and other methods that don't support a request body, the field is hidden.

Switch to POST, PUT, or PATCH to see the body field appear.

Can I use dynamic values from upstream nodes in the URL, headers, or body?+

Yes. All fields support the field mapper for dynamic references. For example, your URL can include a path parameter from the trigger: https://api.example.com/users/{{1:userId}}.

When testing with dynamic references, the Test Data Dialog will ask you to provide sample values to substitute before sending.

Can I add multiple headers?+

Yes. The Headers field is a key-value list — add as many header rows as needed. Common combinations include Content-Type, Authorization, and custom API key headers.

Testing & Output

Why do I need to test before I can save?+

Unlike regular app nodes where the output schema is pre-defined, the Webhook node's output depends on what the target API actually returns. The only way to know the response structure is to send the real request.

The test generates the output schema — without it, downstream nodes have no fields to reference in the field mapper.

Does testing send a real request to the URL?+

Yes. The Test Data button sends an actual HTTP request to the configured URL. If the endpoint is a production API, it will execute the action (create a record, send a notification, etc.).

Use a staging or sandbox endpoint during testing to avoid side effects on production data.

What happens if the test returns an empty or null response?+

If the response body is empty, the output schema will be empty. Downstream nodes won't have any fields to reference from the Webhook.

If your endpoint doesn't return a body (e.g., a 204 No Content), that's expected — just be aware that no output fields will be generated. The workflow will still continue.

Can I manually define the output schema?+

No. The output schema is always inferred from the test execution response. It cannot be manually defined or edited. If the API response structure changes over time, re-test the Webhook to update the schema.

What happens to downstream nodes if I re-test and the response structure changes?+

If you save with a new output schema (after re-testing), Konnectify validates downstream nodes. Any nodes that had field mappings referencing fields that no longer exist in the new schema will be marked as unconfigured.

Review and re-map those fields before activating the workflow.

Behaviour & Restrictions

What happens if I change the HTTP method after testing?+

The test results are automatically cleared — the output schema and test data are reset. You must re-test with the new method configuration before you can save.

This prevents a stale output schema from a different method from being used by downstream nodes.

What does read-only mode mean on a Webhook node?+

All fields are disabled, the Test Data button is hidden, and the Continue button is disabled. This is applied when you lack edit permissions or the konnector is locked during execution.

Can I use the Webhook node inside a Repeater?+

Yes. The Webhook node can be placed inside a Repeater as a child node. It will execute once per iteration, with the current item's fields available for dynamic mapping in the URL, headers, and body.

Be mindful of rate limits on the target API when using a Webhook in a loop — it will fire once for every item in the array.

What is the difference between a Webhook trigger and a Webhook action node?+

Webhook Trigger — Receives inbound HTTP requests. An external service calls your Konnectify endpoint to start the workflow.
Webhook Action Node — Sends outbound HTTP requests. Your Konnectify workflow calls an external service's endpoint.

Ready to build smarter workflows?

Add a Webhook node to your konnector and connect to any HTTP API — no connector needed, no limits on what you can integrate.

Get started free →