Commerce, SaaS, CRM, or ERP—without rebuilding what already works. BailingHub connects capabilities, trusted identity, approvals, and audit to agents so they can act without crossing your system boundaries.
See one business action in 60 secondsAdd every item below 10 units to a replenishment order and save it as a draft. Do not place the order.
842msBusiness operations need APIs, real identities, permission checks, and call records to work together. BailingHub provides that shared integration layer for different agent entry points.Explore identity, permissions, and audit↗
Without a connection to business APIs, an assistant can offer advice but cannot update records, create documents, or start approvals in your system.
Giving a model an all-powerful key, every API, or direct database access leaves overreach and costly mistakes uncontrolled.
Web assistants, local agents, Dify, and n8n quickly become separate islands of identities, tools, and logs.
Your system decides what to expose. Start with low-risk reads, then add creates, updates, workflows, and high-risk actions that require approval.See where BailingHub fits↗
“Find products below 10 units and create a draft replenishment order.”
Read authorized data first, then invoke a deliberately exposed write capability.
“Find staff member Lin and move them to the Riverside store.”
Only fields visible to the current business identity can be changed.
“Check flask stock. If available, set its store price to CNY 59 and publish it.”
Select both systems first; product mapping, business tools, and existing approvals must be in place.
“Start a refund for this order and report the final outcome.”
Business policy decides approval; only the approved request is executed.
Follow an animated product-rename example: the request carries the current identity and allowed capabilities, the agent reads and updates, and the business page shows the result.
Try the player’s play button, or open the video file. Open video file →
The public Docker Demo includes reproducible order lookup, ticket creation, and refund approval scenarios.
The same capabilities do not have to belong to one chat box or agent. Choose the entry point that fits your system and users.Compare every connection path↗
01 / 0302 / 0303 / 03BailingHub Core is Apache-2.0 and can run on your own servers and database. The public Docker Demo reproduces reads, writes, approvals, and failure tracing without a real business system or model key.
$ docker compose up --buildYou do not need to integrate the entire back office on day one. Understand the product, then validate identity, invocation, result, and trace with one sanitized action.
10-minute setup↗The fastest way to understand the console, routes, and execution traces. The public environment is for evaluation only—never upload production credentials or real business data.
Open online trial↗Reproduce order lookup, ticket creation, refund approval, and failure tracing without an existing business system or model key.
Read the Demo guide↗Choose one low-risk read and one governed write, declare them through OpenAPI or an SDK, and verify the complete loop.
Read the integration guide↗No. Keep your backend, accounts, permission tables, and business workflows. Connect selected actions through OpenAPI, ACC declarations, or an SDK. Add capability declarations, trusted identity, and request verification for the operations you choose.
No. It calls server-side capabilities explicitly declared and authorized by the business system, so parameters, identity, permission, and results can all be verified.
Your business system does. BailingHub controls what an agent may discover and request; your backend still executes or rejects each call under the current user, tenant, role, and business rules.
No. Approval follows capability declarations and business policy. Routine authorized writes may execute directly, while sensitive actions can wait for approval.
MCP defines a tool protocol, while Dify and n8n build agents or workflows. BailingHub focuses on trusted business identity, capability scope, approval, signing, execution, and audit between those agents and your systems.
No. You can self-host the control plane and state database while choosing cloud APIs or self-hosted models based on cost, networking, and data requirements. Inputs sent to external models still follow your configured provider.
Yes. Once the host integrates model services, it can use plan-enabled chat models and image tools with a shared allowance, or keep its own model connection. Conversation and tool orchestration stay with the local agent.
Open source, self-hosted, and designed to start with one capability.