Use a Dify Agent or Workflow to submit business actions through a self-hosted BailingHub control plane.
The plugin intentionally exposes only three control-plane tools:
submit_governed_job: submit an action to an administrator-configured route;get_job: read the current state and terminal result of a job;wait_for_job: poll a job for a bounded period without waiting indefinitely.
It does not import governed business APIs into Dify and does not give Dify admin, executor, or business-system credentials.
Dify Agent or Workflow
-> BailingHub Dify Plugin
-> POST /run
-> GET /jobs/{job_id}
-> BailingHub control plane
-> governed executor
-> business system
- Marketplace: Install BailingHub from Dify Marketplace
- Source: github.com/bailinghub/bailinghub-dify-plugin
- Bug reports and support: GitHub Issues
- Security reports: use this repository's private Security Advisory channel as described in SECURITY.md.
This repository is an independent integration adapter. It is not:
- part of the ACC normative specification;
- embedded in the BailingHub server distribution;
- versioned or released together with ACC or BailingHub;
- an official Dify partnership or certification.
The dependency is one-way: this plugin consumes BailingHub's public Client API. See Project Boundaries and Compatibility.
- Dify with Tool Plugin support;
- a reachable self-hosted BailingHub instance;
- a dedicated BailingHub Client Token restricted to the routes Dify needs;
- HTTPS between Dify and BailingHub, except for loopback development.
- In BailingHub, create a dedicated client for this Dify application.
- Allow only the required routes and set an appropriate rate limit.
- Install BailingHub from Dify Marketplace. For offline or pinned-package installation, use a versioned package from this repository's Releases.
- Configure:
BailingHub Base URL: the BailingHub HTTPS origin;Dedicated Client Token: the raw client token, without aBearerprefix.
Never use an admin token, executor token, tool-provider secret, or business-system credential as the Client Token.
- Generate a deterministic
request_idin the workflow, for exampledify:<conversation-id>:<workflow-run-id>:<step-id>. - Call
submit_governed_jobwith an administrator-provided route. - Save the returned
job_id. - Call
wait_for_jobfor a short bounded wait, or callget_jobfrom a later step. - Treat
doneas success. Treaterrorandrejectedas terminal failures.
queued, running, and dispatched are non-terminal. If a bounded wait times out,
query the same job_id later. Do not submit a replacement action. When retrying the
same business request, reuse the same request_id without changing its meaning or
arguments.
Use the Dify integration path as the
canonical start page. The first integration is successful when a job submitted through
the configured route reaches a terminal state under the same job_id, BailingHub retains
its approval and audit state, and Dify never receives administrator or business-system
credentials.
Report a PASS, partial result, or failure through the BailingHub independent validation form and select the Dify track. Never include tokens, model keys, personal information, or production business data.
- Route choice is constrained again by the BailingHub client allowlist.
projectandprofileare not plugin inputs and cannot be overridden by a model.- Responses are limited to 1 MiB and filtered to job state and result fields.
- Arbitrary upstream response bodies are not exposed as errors.
- Non-loopback HTTP base URLs are rejected.
- Final business authorization remains in the business system.
The plugin is an adapter to governance enforcement; it is not the final authorization boundary and does not make model output trustworthy.
The plugin sends requests only to the BailingHub base URL configured by the Dify administrator. See PRIVACY.md for the complete data-flow disclosure.
Python 3.12 and uv are recommended.
uv sync --dev
uv run ruff check .
uv run pytest
uv run python scripts/check_project.pyPackage with a pinned Dify Plugin CLI as described in Releasing.
Apache License 2.0. See LICENSE.