Definition

The HTTP Webhook trigger starts a flow when a specially crafted HTTP request is sent to a unique, automatically generated endpoint. It allows you to connect external systems, apps, or scripts to your workflows in real-time, without requiring polling or manual input. Once triggered, the flow runs asynchronously, meaning the calling system doesn’t need to wait for the flow to complete.

This trigger is ideal for integrating third-party services, receiving real-time data from custom apps, or reacting to system events. It supports key HTTP request data — such as method, headers, body, form values, and query parameters — giving you flexible control over how and when your flow executes.

Example Use Cases

1. Receive Data from an External Form

Trigger a flow when a user submits a custom web form hosted on your website or application. Use the submitted data—such as name, email, or preferences—to automate follow-up actions like storing the information or sending an acknowledgment email.

2. Integrate with a Third-Party App

Start a flow when an external service (like monitoring tools, internal systems, or third-party apps) sends a webhook.Zenphi already provides out-of-the-box integrations with many services. But even if a service isn’t natively supported, as long as it offers APIs, Zenphi can integrate with it using the HTTP Webhook trigger. This ensures that Zenphi can connect to virtually any software platform through a flexible, API-driven approach tailored to your needs.

3. Store Submitted Payloads in a Database

Trigger the flow when your backend sends structured JSON data (e.g., from a mobile app or CRM), and automatically store that information in Google Sheets, BigQuery, or any supported database solution.

4. Filter Requests Based on Origin (Conditional Run)

Only allow the flow to proceed when the request originates from a known source. You can check the remote IP, Headers.Origin, or Allowed Origins in Conditional Run to enforce request filtering and basic security controls.

5. Route by Content (Conditional Run)

Execute the flow only when specific data appears in the request body or query string. For example, you might route leads differently based on region, or only continue if a status field equals “approved”. This makes it easy to build decision-driven flows using Conditional Run logic.

⚙️ Configuration

This trigger allows external systems or users to invoke a flow via an HTTP request. To ensure proper setup and secure access, configuration is divided into three phases. For this trigger, you can adjust several options — some of which are available before publishing the flow (like with any other trigger), while others become available after publishing.

Initial settings can be configured in the Settings tab of the trigger.
Post-publish settings are accessible in the Invocation tab.
Conditional run settings are available in the Conditional Run section of the trigger.

Initial Settings (Pre-publish settings)

These are the initial and required options you must configure before publishing the flow.Once the flow is published, these fields become read-only (greyed out) and cannot be changed.If you ever need to modify them after publishing, you will need to remove the trigger, add a new one, and reconfigure from scratch.

1. URL Identifier

This field defines the last part of your webhook URL and is required to distinguish your endpoint.

Limitations: Must be between 3 and 20 characters, using only lowercase letters, numbers, hyphens, and underscores.
By default, Zenphi auto-fills this field using your flow name. If your flow name exceeds 20 characters, you will see a validation error and need to update it manually.

**Where is this used?**The complete webhook URL is generated using your Workspace ID and this URL Identifier. The format is:

https://webhook-zone1.zenphi.io/httptrigger/{workspace-id}/{url-identifier}

Example:

https://webhook-zone1.zenphi.io/httptrigger/3d6b949a6e404140a1249fe9c8573c6b/production-flow

⚠️
Note: In earlier versions of this trigger, republishing the flow would generate a new URL, requiring you to update the URL wherever it was used.That is no longer the case—your webhook URL now remains stable.However, if by any chance you still see the old behavior or format, it likely means you're using a legacy trigger.To fix it, remove the trigger and add the new version. Welcome to an improved experience with Zenphi!

2. Allowed Origins (CORS)

Here you define which browser-based sources (origins) are permitted to invoke this webhook.

Accepts a comma-separated list of domain URLs like:
```
https://example.com, https://another.com
```
This applies only to browser requests (i.e., when a request is made from JavaScript in the browser). It enables Cross-Origin Resource Sharing (CORS) by specifying trusted sources.

This is useful when you're integrating Zenphi with public or internal web apps and want to ensure that only your frontend app(s) can trigger this flow.

Invocation(Post-publish settings)

Once the flow is published, the Invocation tab appears within the trigger settings. This section gives you the actual URL and authentication method you’ll use to trigger the flow from outside systems.

You have two available options for making the request:

URL Using Authentication Header

This option provides:

A Webhook URL, like:

https://webhook-zone1.zenphi.io/httptrigger/3d6b949a6e404550a1249fe9c7273c6b/production-flow

A Required Header:

x-zenphi-httptriggertoken: [your_token_here]

To trigger the flow using this method, include both the URL and the specified HTTP header in your request.

URL Including Authorization Token

This is a combined version of the above, embedding the authentication token directly in the URL, so you don’t need to set headers separately.

Example:

https://webhook-zone1.zenphi.io/httptrigger/3d6b949a6e445140a1249fe9c7273c6b/production-flow?x-zenphi-httptriggertoken=abc123token

This method is especially convenient for simpler integrations or tools that don’t support adding custom headers easily.

1. Renew Authentication Token

Next to the Auth Header is a lock-and-arrow icon. Clicking this allows you to renew or configure how the authentication token is managed.

Two options are available:

Automatically generate a new authentication token
- Zenphi will handle token creation and rotation for you.
- Just click “Renew Auth Token” anytime to update the token (e.g., for security updates).
I want to provide my own authentication token
- You manually set a custom token.
- Requirements:
  - Length between 5–200 characters
  - Only letters, numbers, hyphens, and underscores

This provides flexibility whether you're using internal scripts, third-party tools, or regulated environments that require custom tokens.

2. HTTP Method

Under the Invocation tab, you can also define which HTTP method(s) your endpoint will accept.Supported methods include:

POST
PUT
GET
DELETE
HEAD

Omit the methods that doesn't align with the system or tool calling your flow.

This configuration setup allows the HTTP Webhook Trigger to integrate securely and reliably with any external system, offering both flexibility and control—before and after the flow goes live.

Conditional Run

The Conditional Run feature lets you define specific conditions that must be met for the HTTP Webhook Trigger to activate the flow. If the webhook is called but the conditions aren’t met, the flow will be skipped automatically — allowing you to filter incoming requests and only process the ones that matter.

This is especially useful when your webhook receives a wide variety of requests, and you want the flow to run only for certain event types, header values, query params, or request body content.

🔁 How Conditional Run Works

When enabled, Conditional Run allows you to build rules using AND / OR logic. Each rule is built using four components:

1. Condition Type

When: The flow will run only if this condition is true.
Except When: The flow will not run if this condition is true.

2. Value to Evaluate

Select what part of the incoming HTTP request you want to apply the condition to. This includes:

Trigger Outputs: All incoming data from the webhook, such as:
- Http Method (e.g., POST, GET)
- Http Body content
- Remote IP of the caller
- Content Type
- Parsed Form Data (as JSON)
- Parsed Query String (as JSON)
- Individual Headers (like Authorization or Content-Type)
Vaults: Static secure values from your workspace, such as API tokens, environment tags, or custom identifiers.

🔐 Vaults are managed from your workspace under Settings → Vaults.They are not editable in flows and are securely referenced at runtime only.

3. Operator

Choose how the comparison should be made. Available options include:

Equals / Not Equals
Greater Than / Greater Than or Equal
Less Than / Less Than or Equal
Between
Is Null / Is Not Null

4. Comparison Value

Define the value to compare against. This can be:

A value from Trigger Outputs
A value from Vaults
Or a manually entered static value (like text, number, etc.)

🧠 Example Conditions for HTTP Webhook Trigger

Skip the flow except when remote IP matches your company network
Run the flow only when a specific header (e.g., x-source-app) equals AppSheet
Run the flow only when the content type is application/json
Run the flow only when a value inside the form data or query string matches a predefined Vault key

This flexible logic helps you validate and filter incoming requests based on structure, source, or purpose — ensuring your flow runs only for requests that match your intended logic.

Outputs

When the HTTP Webhook Trigger is invoked, it captures and passes along data from the incoming HTTP request. These outputs are automatically available throughout your flow and can be used in:

Any action using the Token Picker
The Conditional Run section of both the trigger and individual actions

Below is a description of each available output:

🔹 Http Method

**(The HTTP method used to make the request — e.g., GET, POST, PUT)**This tells you which HTTP verb was used when the trigger was called.

Useful if you want to handle requests differently based on whether it's a data read (GET) or write (POST, PUT).

🔹 Http Body

**(The raw body content sent with the request)**This is the actual data payload of the request, usually in JSON format.

For example, if a web form sends user responses, those details appear here.

🔹 Remote IP

**(The IP address of the sender making the request)**This output shows where the request originated from, helping with logging, monitoring, or restricting access.

Especially useful for security or audit purposes.

🔹 Content Type

**(The type of content sent in the request — e.g., application/json, application/x-www-form-urlencoded)**Indicates how the data was formatted.

Helps decide how to parse or handle the incoming data correctly.

🔹 Form Data

**(Form data from the request converted into a JSON string)**If the request contains form-encoded data, it is automatically extracted and converted into a usable JSON format.

Great for when working with HTML forms or low-code tools submitting structured data.

🔹 Query String Data

**(Query string parameters converted into a JSON string)**Any key-value pairs appended to the URL (after a ?) are extracted here.

Example: If the URL is ...?user=john&status=active, this output will include both values in JSON format.

🔹 Headers

**(All HTTP headers included in the request)**These are the metadata fields in the request, such as Content-Type, Authorization, or custom app headers. Each header has two parts:

Header Name – e.g., Authorization
Header Value – e.g., Bearer token_xyz

Headers are often used for authentication, tracking, or custom app behavior.

Example: Connect AppSheet to Zenphi Using HTTP Webhook Trigger

Let’s walk through a real-world example of using Zenphi’s HTTP Webhook Trigger inside an AppSheet process.

Scenario

You’ve built an internal AppSheet app where users submit a form and select one or more files from Google Drive. When the form is submitted:

The webhook step in AppSheet makes a POST request to your Zenphi flow via HTTP Webhook.
The payload includes basic form data (e.g., customer name, email) along with Google Drive file IDs that were selected by the user.
In Zenphi:
- The trigger receives the data using the HTTP Webhook Trigger.
- The file IDs are used to retrieve and merge those documents.
- The final merged document is saved to OneDrive.
- A confirmation email is sent to the user.

This is a powerful, flexible way to run advanced document operations and multi-step automation starting from a simple AppSheet action.

Why This Matters

Zenphi’s HTTP Webhook Trigger lets you extend your automations beyond Google Workspace. Whether it’s AppSheet, a custom website, or another external platform, if it supports HTTP calls — you can call Zenphi.

😊
You can access Zenphi from anywhere. That’s the power of the HTTP trigger.

Definition

Example Use Cases

1. Receive Data from an External Form

2. Integrate with a Third-Party App

3. Store Submitted Payloads in a Database

4. Filter Requests Based on Origin (Conditional Run)

5. Route by Content (Conditional Run)

⚙️ Configuration

Initial Settings (Pre-publish settings)

1. URL Identifier

2. Allowed Origins (CORS)

Invocation(Post-publish settings)

URL Using Authentication Header

URL Including Authorization Token

1. Renew Authentication Token

2. HTTP Method

Conditional Run

🔁 How Conditional Run Works

1. Condition Type

2. Value to Evaluate

3. Operator

4. Comparison Value

🧠 Example Conditions for HTTP Webhook Trigger

Outputs

🔹 Http Method

🔹 Http Body

🔹 Remote IP

🔹 Content Type

🔹 Form Data

🔹 Query String Data

🔹 Headers

Example: Connect AppSheet to Zenphi Using HTTP Webhook Trigger

Scenario

Why This Matters

😊You can access Zenphi from anywhere. That’s the power of the HTTP trigger.

😊
You can access Zenphi from anywhere. That’s the power of the HTTP trigger.