Dify, n8n, local agents, and custom services should not each rebuild job state, approvals, audit records, and traces. Independent adapters consume the public BailingHub Client API; BailingHub governs reach and execution, while the business system retains final authority.
Statuses describe public availability or review progress only. They do not imply certification, recommendation, partnership, or security endorsement by an ecosystem platform.
For custom agents, backend services, and any runtime that can make HTTP requests. Submit governed jobs, query state, or wait within a fixed bound without adopting a specific agent platform first.
Submit BailingHub governed jobs and read their state from a Dify workflow or agent. The plugin is listed in Dify Marketplace, providing a searchable and installable upstream entry point.
The npm package is available now. It submits jobs, checks status, waits within a fixed bound, and returns public trace, approval, and audit state. Automated review passed; n8n manual review is pending.
Let a local or remote OpenClaw instance become an outbound BailingHub executor. The skill is public on ClawHub and can be searched, inspected, and installed directly.
A first integration only needs to prove that one business request receives a stable job identity, enters the governed path, and ends in a traceable terminal state. A successful install, health check, or console view does not prove that loop.
Start: run the Docker Demo, then call POST /run with a dedicated Client Token, retain the returned job_id, and query that same job.
Pass: the job reaches an explainable terminal state. A bounded-wait timeout leads to another query, not a duplicate business action.
Start: install the Marketplace plugin, configure the BailingHub URL and a dedicated Client Token, then run submit_governed_job → wait_for_job against a no-side-effect route.
Pass: Dify receives a stable job_id and terminal state without holding BailingHub administrator or business-system credentials.
Start: install n8n-nodes-bailinghub from Community Nodes, create a dedicated credential, and connect Submit Governed Job → Wait for Job.
Pass: the wait node polls the same job and returns its terminal state without resubmitting on timeout. See the installation guide.
Start: run clawhub install bailinghub/bailinghub-executor, review the installation contract, and configure only a target-scoped executor token.
Pass: the executor uses outbound connectivity for heartbeat, claim, and result delivery, opens no inbound port, and does not pass BailingHub credentials to the task agent. See the ClawHub listing.
Keep each platform's orchestration and interaction model.
Translate platform events into the public API contract.
Jobs, approvals, execution, audit, and traces.
Identity, permissions, business validation, and data isolation.
MCP provides tool discovery and transport; BailingHub does not replace it. Start with the responsibility map to separate transport, runtime governance, and final business authorization. This page does not claim an official MCP server or Registry listing.
Marketplace, npm, and community directories provide discovery and installation paths. Production suitability still requires source review, secret configuration, business authorization checks, and runtime validation by the deployer.
Adapters connect to the BailingHub deployment you operate. Whether model inputs leave that deployment boundary depends on the model provider and endpoint you select.
An adapter and the hub can constrain what an agent may reach. They cannot replace the business system's decision about what an acting subject may do right now.
Build an independent adapter against the public Client API first. For industry integration, private deployment, or joint delivery, see Delivery.
Choose a low-risk, verifiable operation. Complete job submission, business authorization, execution, and audit before widening the agent's reach. PASS, partial, and failed reproductions are all useful when the evidence is sanitized.