Outbound Webhook Step Overview – Streamline

The Outgoing Webhook step allows your workflow to send data from Streamline to an external system using an HTTP request. This step is ideal for triggering actions in another system, sending form data or files, or integrating Streamline with internal APIs, CRMs, and other services.

With the Outgoing Webhook step, you control:

Where the request is sent (endpoint URL)
How it is sent (HTTP method, authentication, headers)
What information is included (body content, parameters, files)
Whether you want to test and preview the response before publishing the workflow

This step can be used together with a Webhook Integration for authenticated requests or with public endpoints.

Common Use Cases

Use the Outgoing Webhook step when you want to:

Notify another system when a Form or Document step completes
Create or update a record in a CRM, ticketing system, or database
Trigger internal automations or downstream jobs
Upload files gathered earlier in the workflow
Query an external API to inform subsequent workflow decisions

Before You Begin: Webhook Integration (If Needed)

If your external system requires authentication, create the connection under Integrations first.

Supported authentication options include:

Basic Authentication (username + password)
API Key
Bearer Token (OAuth 2.0) - Client ID, Client Secret, Token URL
Custom (Key-Pair Value)

Once saved, this connection becomes available under Connection Type → Authenticated in the Outgoing Webhook step.

Please see this article for more information.

Adding the Outgoing Webhook Step to Your Workflow

To add an Outgoing Webhook step to your workflow:

To add an Outgoing Webhook step, open your workflow and click Add Step, then search for and select Outgoing Webhook from the list of available steps.
(Optional) Rename the step to help keep your workflow organized.
Click Edit (or click directly on the step) to begin configuring the webhook.

Once the step is added, all setup happens inside the Request and Response tabs.

Configuring the Request Tab

All webhook behavior is defined within the Request tab. This includes connection settings, URL configuration, parameters, headers, and the request body.

Connection Type

Choose how your webhook will authenticate:

Public

Use when the endpoint does not require authentication.
Common for testing tools like Beeceptor or Mockly.

Authenticated

Use when the endpoint requires credentials.
Select your saved Webhook Integration.
Streamline automatically applies any required authentication headers.

HTTP Method

The HTTP method determines what kind of action your webhook performs.

GET – Retrieve data

Use when you want to request information from another system.

Example: Retrieve an order status or fetch customer details.

POST – Create or send data (most common)

Use when you want to send data—such as form responses—to another system.

Example: Create a new CRM record or trigger an automation.

PUT – Update an existing resource

Use when you need to update a record in an external system.

Example: Update a customer profile, ticket, or status field.

DELETE – Remove a resource

Use when you want to delete something in the external system.

Example: Delete a file, remove a record, or close a session.

If GET is selected, the Body section is hidden because GET requests rarely include bodies.

Endpoint URL

Enter the full URL where your webhook will be sent.

Examples:

https://api.example.com/webhooks/create

https://your-test.free.beeceptor.com/orders

You may also include dynamic path parameters, such as:

https://api.example.com/users/:userId/files/:fileId

Streamline automatically detects these placeholders and displays them in the Path Parameters section.

Path & Query Parameters

Under Request → Parameters, you can configure dynamic and static values associated with the URL.

Path Parameters

Automatically generated from your URL (e.g., :userId)
Keys are fixed; you assign the Values
Values may be static or mapped from earlier workflow steps

Query Parameters

Add your own key/value pairs using Add key/value
Values may also be static or mapped dynamically
Optional: Remove all query parameters using Delete all

Adding Headers

Under Request → Headers, you can add any custom HTTP headers required by the external service.

Use Add key/value to define your own headers
Header values may be static or mapped from earlier workflow steps
Content-Type headers may be needed depending on your API’s requirements

When using an authenticated Webhook Integration, certain authentication-related headers may appear automatically in the Headers tab. These headers:

Are generated based on your selected authentication method
May include values such as Authorization
Are read-only and cannot be deleted

If you add a custom header in the Headers tab that uses the same key as an automatically generated authentication header, the custom header you define will overwrite the header provided by the integration. This allows advanced users to override or customize authentication behavior when necessary.

Common examples of headers you may add manually:

Content-Type: application/json
Accept: application/json
X-API-Version: 2
X-Custom-Token:{{`Form`.`token`}}}

Choosing a Body Mode & Writing JSON or Plain Text

Under Request → Body, choose how the webhook request body should be formatted.

(Body configuration will only appear for POST, PUT, or DELETE.)

Raw (JSON or Text)

Use for structured JSON or message-style text.

JSON mode supports mapping fields using:

Drag and drop fields from previous steps using the Data Fields tab; they appear in curly-brace format automatically
Supports Base64-encoded files (up to 10 files, each ≤ 10MB)

Multipart Form

Use when you need to send a mix of text values and files.

Ideal for file upload endpoints
Supports file mapping up to ~100MB
Uses key/value-style configuration

Binary File

Use when sending a single large file (up to 2GB) as the entire request body.

Only one field: the mapped file
Recommended for APIs expecting a raw file upload stream

Using the Response Tab

The Response tab allows you to test how your endpoint responds before publishing your workflow. It also enables you to wait for and capture the response, so you can map the returned data to downstream steps in your workflow.

Enable Wait for a Response

Toggle Wait for a response to run the webhook synchronously.

Send Test Request

Once the test request is submitted, Streamline will:

Send the request to your endpoint
Wait for the response
Display the response payload in the panel

You can send additional test requests as needed.

Note: Sending a new test overwrites the previous response.

Extracting Fields from the Webhook Response

After you send a test request and receive a response, you can use the Extract Fields section to choose which fields from the webhook payload you want to make available in your workflow.

Choosing Response Fields

Select the fields you want to extract (for example, orderId, status, or nested fields such as customer.email)
Each selected field will create a corresponding output field in your workflow

Using Custom Instructions

If the response requires additional guidance for field extraction, you can write custom instructions in the provided text box.

This helps the system understand how to interpret or locate the correct values, especially when:

The response structure is complex
Data is nested deeply
Field names are inconsistent
Multiple values need to be derived from a single response field

Custom instructions can describe what you want to extract, the format expected, or how the AI should interpret the response payload.

Considerations When Using the Outgoing Webhook Step

HTTP Methods Not Supported

PATCH method is not available

Request/Response Format

JSON only - XML and Form-data request/response formats are not supported
Request and response bodies must be valid JSON

File Handling Constraints

Base64 encoded files are limited to 10 files maximum per request
Each Base64 encoded file is limited to 10MB maximum
Progress indication for large file uploads may be limited in synchronous operations

Synchronous Operation Only

The Outgoing Webhook step operates synchronously - the workflow step waits for the API response before proceeding
There is no asynchronous option for long-running API calls or large file uploads
Users should be aware that slow external APIs may impact overall workflow execution time

Timeout Behavior

API calls are subject to timeout limits
If an external API exceeds the timeout threshold, the step will fail and retry logic will apply
Specific timeout values should be considered when integrating with slower external systems

Compliance

No additional compliance considerations specific to this feature at this time. The Outgoing Webhook step follows existing Intellistack Streamline security and data handling practices.

Troubleshooting Common Issues

Best Practice: Test API Calls Before Implementation

Before configuring an Outgoing Webhook step in Streamline, it is strongly recommended to test your API calls using a third-party API testing tool such as Postman or Bruno. This allows you to:

Verify that your endpoint URL, headers, and authentication are configured correctly
Confirm the expected request and response formats
Troubleshoot any API-specific issues before introducing them into your workflow

Once you have confirmed that your API calls work as expected in an external tool, you can confidently configure the same calls in your Streamline workflow.

Authentication Failures

If your Outgoing Webhook step is failing with authentication errors:

Verify that your credentials are correctly configured in the Integrations Marketplace
Ensure the authentication method selected in the workflow step matches what the external API expects
For OAuth 2.0, confirm that the Token URL is correct and accessible

Unexpected Response Formats

If you are not receiving the expected data in your workflow:

Confirm the external API returns JSON responses
Check that you are referencing the correct path in the response object when mapping data to subsequent steps
Use an API testing tool to view the raw response structure

Timeout or Slow Responses

If your Outgoing Webhook steps are timing out:

Test the external API's response time using Postman or Bruno
Consider whether the external system may be experiencing performance issues
For APIs that routinely take longer to respond, plan your workflow design accordingly