How to integrate Unify with Cloudflare Workers + Workflows
To integrate Unify with Cloudflare Workers and Workflows, POST prospect JSON to a Worker fetch handler. The Worker checks the request and starts a Workflow through a binding. Track the Workflow instance and destination result separately from the HTTP acknowledgement sent back to Unify.[1][3]
- Connection
- Custom webhook
- Developer platforms
- Tool
- Cloudflare Workers + Workflows
- Worker fetch handler
- Data flow
- Unify → Cloudflare Worker → Cloudflare Workflow
- JSON payload
At a glance
- Authenticate the Worker before creating an instance
- Pass only validated fields into Workflow parameters
- Track instance completion and repeatable side effects separately
When this workflow makes sense
Start with the decision your team needs to make, then choose the connection that supports it.
Some handoffs need several application steps and a clear way to recover when a dependency fails. A Worker can act as the front door while a Workflow owns the longer process. Design the checkpoints around observable outcomes: accepted input, created instance, successful steps, and completed destination action. Each boundary should have an owner and a defined recovery decision.
A good fit when
Teams already using Cloudflare who need a durable process with multiple steps, waits, or retries after receiving prospect data.
Reconsider the plan when
A single quick action may only need a Worker. Introduce a Workflow when its durable execution model solves a real need, and avoid assuming retries make external side effects exactly once.
Design the handoff
Use this framework to agree on the input, the next action, and who owns the result.
Suggested workflow design, based on the documented capabilities below.
| Stage | Decision to make |
|---|---|
| Intake | Authenticate the Worker request and validate the fields allowed into the process. |
| Instance | Choose how an incoming handoff maps to a Workflow instance and record its ID. |
| Recovery | Define which steps may retry and how their side effects tolerate repetition. |
| Outcome | Check the final instance state alongside the result in the destination system. |
Explore the scenarios
Choose the situation that fits your team and work through the proposed plan.
Open a scenario to explore its plan. Checklists track your selections in this page only.
Run a process with recoverable steps
A selected prospect needs several application actions and one dependency can fail temporarily.
Give each step an observable result and an intentional retry policy. Preserve the distinction between a failed step and a failed intake request.
- Validate the prospect in the Worker and create an instance
- Implement the application actions as Workflow steps
- Simulate a temporary dependency failure and inspect recovery
Separate request repeats from step retries
A sender timeout can lead to another webhook while the first Workflow is already running.
Decide how to recognize a repeated handoff before choosing instance IDs. Step retries and multiple instances are different sources of repeated actions.
- Choose a stable handoff identity available to the receiver
- Implement the intended behavior when that identity already exists
- Send the same sample twice and compare instances and side effects
Illustrative workflow, not a preconfigured automation. Complete these checks in your own account.
Define success before launch
Inspect the data and the intended outcome separately. Connection status is only the first check.
Expected, not tested
The Worker starts the intended Workflow with the sample prospect, and the final Workflow state and destination result agree.
Record the instance ID in an operator-visible system. Check its status and actual side effects. The HTTP response acknowledges instance creation, while the Workflow may still be queued, running, or waiting.
Documentation-based reference. This workflow has not been tested end to end. Use a record or event you control before enabling live activity.
Questions answered
Common decisions when connecting Unify and Cloudflare Workers + Workflows.
Does Unify call the Worker or the Workflow?
In this design, Unify calls the Worker’s HTTPS endpoint. The Worker starts a Workflow through its configured binding.[3]
Where does the Workflow find the prospect data?
Pass the validated object as params when creating the instance. The Workflow receives that object through event.payload.[4]
Can the Workflow keep running after the webhook response?
Yes. The Worker can acknowledge instance creation while Workflow execution proceeds separately. Inspect the instance’s final state before treating the operation as complete.[3]
Are Workflow retries the same as webhook retries?
No. Workflow retry configuration governs steps within an instance. Unify request retries can reach the Worker again. Your design must account for both boundaries.[5]
Do durable retries prevent duplicate external actions?
Design each side effect to tolerate a repeat. A retried step may call an external service again; use the destination’s supported deduplication method or an application-owned record of the action.[5]
Limits & decisions
Check these boundaries before designing a live workflow around the connection.
- Requires custom Worker and Workflow code, deployment, and bindings
- A Workflow instance ID in the response is not consumed by later Unify Play steps
- Longer Workflow execution does not extend the sender’s 8-second HTTP deadline
- Workflow durability does not replace application-level identity and duplicate handling
- No live Worker invocation or Workflow execution has been tested
What the connection supports
Understand the connection, the data involved, and the behavior that matters for a Unify + Cloudflare Workers + Workflows workflow.
POST / JSON to a Worker, then Workflow instance creation
| Decision | What to know |
|---|---|
| HTTP entry point | A Worker fetch handler can trigger a bound Workflow[3] |
| Parameters | create receives params; the Workflow reads event.payload[4] |
| Execution | Workflow steps support retries and durable waits[5] |
| Secret storage | Workers secrets expose private values to the server-side environment[6] |
| Completion | An instance status can be inspected separately from its creation response[3] |
Technical setup reference
References and requirements for the Cloudflare Workers + Workflows connection.
Connection requirements and setup checklist
Before connecting
- A Unify Play with a Webhook action
- A Cloudflare Worker, a deployed Workflow, and a binding between them
- A developer responsible for request authentication and Workflow step behavior
- An agreed instance identity, destination actions, and completion record
Define the durable work
Implement a Workflow with the steps your process needs. Choose which external actions should run in step.do, which failures are retryable, and how each action recognizes a repeat. These application decisions are not supplied by a webhook trigger.[5]
Request configuration
- Method
POST- URL pattern
https://YOUR_WORKER.YOUR_SUBDOMAIN.workers.dev/unify-webhook- Headers
Content-Type: application/jsonX-Unify-Webhook-Key: YOUR_WEBHOOK_SECRET- Authentication
- Suggested custom authentication: implement a check for X-Unify-Webhook-Key in your receiver and store the expected value as a server-side secret. In Unify, choose API Key (Header), use that header name, and enter the matching value. The header name is chosen for this example; the platform does not validate it automatically.
Choose JSON as the body format. Unify sets Content-Type automatically. The receiver must respond within Unify’s 8-second timeout; request responses are not passed to later Play steps.[2]
Replace URL placeholders with the actual receiver URL from your account or deployed application. These example URLs are not working endpoints.
Example handoff payload
Start with a fictional prospect. Validate the resolved values before using a real record.
Inspect the sample payload and field mapping
{
"event": "prospect_handoff",
"prospect_name": "Alex Morgan",
"prospect_email": "alex@example.com",
"company_name": "Example Company",
"company_domain": "example.com"
}Fictional data. Replace sample values before using a real Play.
The keys are an example handoff format, not required Unify field names. Use the field mapping to distinguish record data from fixed settings. Select available fields in your Play and inspect Expand preview; do not replace configuration values with prospect data.[2]
| Payload field | Value to send |
|---|---|
event | A fixed label you choose for this workflow |
prospect_name | Use {{ person.first_name }} and {{ person.last_name }} for the prospect name |
prospect_email | Use {{ person.email }}; decide how to handle missing values |
company_name | Use {{ company.name }} |
company_domain | Use {{ company.domain }} |
The Worker maps validated prospect properties into the Workflow params object; the Workflow reads them from event.payload. Choose a durable identity for the handoff. The example event value is a category label and must not be reused as the ID for every instance.
Troubleshooting
Start with the stage where the expected data or action stops appearing.
The Worker receives data but cannot start the Workflow
Check the binding name, target class, and deployment configuration. Inspect the error from create before returning an acknowledgement.[3]
The Workflow receives empty or unexpected values
Compare the validated object passed as params with the fields read from event.payload. Keep parameter names aligned across the Worker and Workflow.[4]
Sources & review
Official documentation reviewed on September 15, 2026.
Technical claims link to primary documentation from Unify and the destination tool. Scenarios, field choices, and recovery plans are editorial implementation examples. Documentation review is separate from execution testing.
Documentation reviewed; end-to-end execution not tested. No named technical reviewer has signed off on these articles yet.
Content updated: . Report a correction to Unify with the tool name, source URL, and behavior you observed.
Keep exploring
