OpenClaw + Dify: Reach Your Workflows from Every Channel

Which system owns the conversation

Decide this before you wire anything. If Dify owns the conversation, your agent should pass a message through and return the answer largely untouched — a thin transport. If the agent owns the conversation, Dify becomes one tool among several, called when a request matches what that workflow does well.

Mixing the two is where behaviour gets strange: two systems both maintaining conversational state, each unaware of the other's memory, producing answers that contradict each other one turn apart. Pick an owner and keep the other side stateless.

1. Publish the app and take its key

In Dify, publish the application and create an API key for it. Note the API base URL — typically your Dify host followed by /v1. Follow the Dify documentation for the current key and endpoint layout, and keep the key scoped to this one app.

2. Connect it from Dashboard Tools

Open Dashboard Tools, select a running instance, and connect the Dify card. The placeholder endpoint is https://dify.example.com/v1. The connector installs a scoped HTTP client plus a managed skill, so the agent knows the endpoint exists and which calls are safe to make. The client lives at a managed path — tools/dashboard-api-connectors/dify/tool — and the examples below use tool as shorthand for it.

# Read the app's declared inputs before calling it
tool get /parameters

# Send one message
tool post /chat-messages '{"inputs":{},"query":"Hello","user":"openclaw","response_mode":"blocking"}'

Starting with /parameters matters: it tells the agent which variables the app actually expects, which is far more reliable than guessing field names from a prompt. Two request details catch people out. inputs is required even when the app has no variables — send {}, not nothing. And response_mode defaults to blocking, which Agent-type apps reject with a 400; those need streaming, so check the app type before wiring the call.

3. Identify the end user honestly

The user field is how Dify separates conversations and attributes usage. Pass a stable identifier per end user rather than one shared constant, or every conversation in your Dify analytics collapses into a single blended session and per-user rate limits stop meaning anything.

4. Keep the wrapper thin

• Do not re-summarise a Dify answer with your agent's model unless the reformatting is the point — that is a second bill for the same content.
• Return Dify's citations if the workflow produces them; dropping them turns a grounded answer into an unverifiable one.
• Handle the workflow's error responses explicitly instead of letting the agent improvise an answer when the call fails.
• Printed responses cap at 5 MB and the client sets a 120-second socket timeout — a stalled-connection bound, not a total runtime budget. Long-running workflows still need an async pattern and a real deadline on the Dify side.

Production hardening

• One API key per application per instance; rotate on staff changes and revoke in Dify, not by deleting the connector.
• Serve Dify over TLS with authentication at the edge; the app API accepts arbitrary user input by design.
• Watch Dify's own model spend — a channel that suddenly reaches thousands of users multiplies workflow calls, not agent turns.
• Version the workflow. A published change takes effect immediately for every connected channel.

Dify versus the other workflow platforms

Dify is the most product-shaped of the three: applications, published APIs, and observability out of the box. Langflow is closer to a visual canvas you deploy as an endpoint, and LangChain is the code-first option when the logic belongs in a repository rather than a UI. All three connect the same way: an authenticated HTTPS endpoint the agent calls as a tool.

Frequently asked questions

Related guides

• Dify in the tools catalog
• OpenClaw + Langflow
• OpenClaw + RAGFlow