CONNECT

Decide who plans and where identity comes from,then choose an integration path

The same platform name can hide very different runtime modes. BailingHub separates five paths by workplace, orchestration, and trusted identity.

Choose an entry path Open integration docs

Five integration pathsIdentity model shown per pathMaturity and boundaries are explicit

01FIVE INTEGRATION PATHS

Connect the layer you actually need

Each path explains orchestration, identity, and maturity so Agent Client, MCP, and executors are not conflated.

WEB ASSISTANT01

Core

Work inside the existing back office

Embed the official assistant so users can query and operate from familiar pages.

Read the setup guide↗

Goal: Add natural-language operations to commerce, SaaS, CRM, or ERP without rebuilding it.
Orchestration: BailingHub handles conversation, routing, and tool orchestration centrally.
Identity: The business system issues a short-lived trusted ticket from the current login.
Boundary: SDK and ticket integration are required; the backend remains final authority.

AGENT CLIENT02

Released v0.3.0

Let a local agent operate the business

Give a local agent a revocable business identity and governed dynamic tools.

Agent Client SDK v0.3.0↗DSH adapter v0.3.0↗

Goal: Query, update, and run permitted capabilities from a desktop or local agent.
Orchestration: The local agent plans; BailingHub supplies rules, capabilities, approval, and audit.
Identity: Browser authorization through a Client App, with multiple connections and identities.
Boundary: It is not an executor and never bypasses Hub governance or business permissions.

API · MCP · AUTOMATION03

Multi-platform

Connect existing agents and automation

Start governed tasks from custom apps, Dify, n8n, an MCP host, or an agent skill.

Read Client API docs↗MCP Server↗

Goal: Reuse existing flows while keeping unified jobs, approvals, and audit.
Orchestration: The caller submits an objective; BailingHub manages routing and job lifecycle centrally.
Identity: Usually a route-scoped Client Token managed by the operator.
Boundary: MCP here is Client Token job mode; Agent Session belongs under Agent Client.

EXECUTOR04

Runtime

Run Hub jobs locally or inside a private network

Handle code review, local files, private-network work, and specialized tools.

OpenClaw Executor↗

Goal: Connect a dedicated runtime without exposing a public inbound port.
Orchestration: BailingHub dispatches a Job; the executor claims, heartbeats, runs, and reports it.
Identity: A target-scoped Executor Token over an outbound connection.
Boundary: An executor is not an interactive Agent Client and does not inherit a user login.

BUSINESS ADAPTERS05

Adapter-specific

Expose capabilities from an existing system

Use business SDKs, packaged adapters, or reference recipes for declaration and execution.

CRMEB adapter v2.4.1↗Business SDKs↗

Goal: Reduce repeated integration work across commerce, SaaS, CRM, and ERP systems.
Orchestration: BailingHub understands and governs; the adapter executes under backend authority.
Identity: Reuse the source system user, tenant, role, and permission model.
Boundary: CRMEB is publicly listed; RuoYi and JeecgBoot are community reference recipes.

02PUBLIC ECOSYSTEM ENTRIES

Find the path first, then prove one end-to-end result

This catalog includes only publicly discoverable Core capabilities, independent adapters, marketplace entries, and community recipes. Every item states maturity, orchestration, identity, version or status, and a first-success path.

A listing, registry entry, or community recipe proves a public distribution or reproduction path—not adoption, certification, recommendation, or security endorsement by the third-party platform. Candidates still under review are excluded.

01 · WEB ASSISTANTView path↗

Public Core capability

BailingHub embedded assistant

Included in a stable Core tag; each real business integration still requires acceptance

Orchestration: BailingHub centrally handles conversation, routing, and tools.
Identity & auth: The business system issues a short-lived trusted ticket from the active login.
Version / status: BailingHub Core v0.5.1
First-success path: Integrate the business SDK and ticket → embed the assistant → complete one read and one permitted write → compare the native record with the trace.

Setup guide↗

02 · AGENT CLIENTView path↗

Independent local-agent adapter

DeepSeek Harness Agent Client

Stable package is publicly installable; the maintainer has validated browser authorization, multiple connections, reads, and permitted writes

Orchestration: The local DSH agent plans; BailingHub projects rules and capabilities and retains approval, recovery, and audit.
Identity & auth: Browser authorization, PKCE, and a revocable Agent Session; no Client Token.
Version / status: dsh-bailinghub v0.3.0 · SDK v0.3.0 · Core v0.5.1
First-success path: Install → set the public connection configuration → run /bailinghub login → complete one read and write → inspect the matching Hub conversation and tool trace.

Plugin v0.3.0↗Agent Client SDK v0.3.0↗

03 · API · MCP · AUTOMATIONView path↗

Workflow / agent tool plugin

Dify Marketplace plugin

Publicly listed in Dify Marketplace; the maintainer validated the 0.1.2 install and the existing no-side-effect path in Dify Cloud

Orchestration: Dify submits an objective; BailingHub centrally owns the governed job lifecycle.
Identity & auth: A dedicated route-scoped Client Token stored in Dify credentials.
Version / status: Plugin 0.1.2 · Marketplace installable
First-success path: Install from Marketplace → set Hub URL and dedicated token → submit_governed_job → wait_for_job → reach a terminal state under one job_id.

Dify Marketplace↗Plugin source↗

Automation workflow node

n8n community node

Verified Community Node and searchable in n8n Cloud

Orchestration: n8n composes the workflow; BailingHub governs each business job.
Identity & auth: A dedicated Client Token stored in an n8n credential; no Hub-admin or business credential.
Version / status: n8n-nodes-bailinghub 0.1.1 · available in Cloud
First-success path: Add the node and credential → connect Submit Governed Job to Wait for Job → verify that waiting polls the original job_id only.

npm package↗Node source↗

Portable Agent Skill

SkillHub Agent Skill

Publicly listed on SkillHub

Orchestration: The agent workspace submits a task; BailingHub centrally plans and governs the rest.
Identity & auth: The operator fixes Hub URL, one route, and a route-scoped Client Token outside the model.
Version / status: bailinghub-governed-actions 0.1.1
First-success path: Install the Skill → set URL, route, and token in secret configuration → run a no-side-effect task → submit, inspect, or wait on the same job_id.

SkillHub listing↗

Portable Agent Skill

Qoder / QoderWork Skill

Publicly visible in Qoder Marketplace; real QoderWork secure-configuration and no-side-effect E2E remain trigger-based validation

Orchestration: The Qoder workspace submits a task; BailingHub owns routing, execution, and terminal state.
Identity & auth: The operator fixes Hub URL, route, and Client Token in secure configuration, never in chat.
Version / status: BailingHub Governed Actions 0.1.1 · public listing
First-success path: Install from the public page → inject the three deployment values securely → run a no-side-effect task → inspect job_id and terminal state; do not raise maturity before platform E2E.

Qoder Marketplace↗

stdio MCP compatibility entry

BailingHub MCP Server

Stable package with public registry and distribution entries

Orchestration: The MCP host submits an objective; BailingHub centrally orchestrates the job.
Identity & auth: Process configuration fixes Hub URL, one route, and a route-scoped Client Token.
Version / status: bailinghub-mcp-server v0.3.0
First-success path: Start the 0.3.0 stdio server → set a dedicated token and fixed route → submit and bounded-wait on one job → query again after timeout instead of resubmitting.

MCP Server v0.3.0↗npm package↗

04 · EXECUTORView path↗

Outbound executor

OpenClaw Executor Skill

Publicly searchable and installable on ClawHub

Orchestration: BailingHub creates and dispatches the Job; OpenClaw claims, heartbeats, executes, and returns the result.
Identity & auth: A target-scoped Executor Token, never an end-user business login.
Version / status: Public ClawHub listing · independently versioned
First-success path: Install from ClawHub → configure only the Executor Token → observe heartbeat → claim a test Job → return a verifiable result under the same Job ID.

ClawHub listing↗

05 · BUSINESS ADAPTERSView path↗

Independent business adapter

BailingHub for CRMEB

Publicly listed in the CRMEB official marketplace; not an official CRMEB product or endorsement

Orchestration: BailingHub understands and governs; the plugin calls original CRMEB services under final backend authorization.
Identity & auth: The active CRMEB administrator, role, and native permissions.
Version / status: Adapter 2.4.1 · validated on CRMEB-KY v6
First-success path: Install → configure the Hub connection in CRMEB and register the tool provider in BailingHub → run a permitted action as a normal admin → compare the native CRMEB record with the trace.

CRMEB marketplace↗Adapter v2.4.1↗

Community integration recipe

RuoYi-Vue-Pro

Public reference recipe, not an upstream official integration

Orchestration: BailingHub governs the action; a thin adapter reuses the existing after-sales service, tenant context, and permissions.
Identity & auth: The source login, tenant context, and trade:after-sale:* permissions.
Version / status: Version-neutral reference · validate against your own release
First-success path: Implement one after-sale read and refund write → prove the read → then verify approval, argument snapshot, idempotency, and the native record.

English recipe↗

Community integration recipe

JeecgBoot

Public reference recipe, not an upstream official integration

Orchestration: BailingHub governs the action; a thin adapter invokes the original JeecgBoot user service.
Identity & auth: TenantContext, original Shiro permission, and operator/target tenant membership.
Version / status: Version-neutral reference · validate against your own release
First-success path: Implement user read and freeze/unfreeze → prove native permission denial still works → match approval, idempotency, native record, and trace.

English recipe↗

03DO NOT CONFLATE

Similar names do not mean the same runtime

Choosing the wrong path often means the orchestration, identity, and security boundary were understood incorrectly.

01Agent Client

Local planning

A local agent receives projected capabilities and plans.

02Client API / MCP

Central planning

The caller submits an objective and the Hub owns the job lifecycle.

03Executor

Job runtime

Claims a Hub-created Job and does not represent a signed-in business user.

04Business adapter

Final execution

Runs inside the source system under its existing permission model.

Not sure which path fits? Start from where the user works

A business console, local agent, automation flow, and private runtime each map to a different integration path.

Explore use cases Open integration docs