# Fused > The Integration Gateway. One governed path from your applications, agents, and development teams to every service they depend on — running in your own infrastructure. Fused sits between the software using an integration and the services being accessed. For every interaction it decides what is allowed to run, resolves the required access, applies policy, performs the provider interaction, and records the outcome. It is not an iPaaS, a workflow builder, or a canvas with boxes joined by arrows. Your application keeps its business logic. Fused takes the integration layer underneath it. ## How it fits together Fused has two components: - **Registry** defines and distributes the integration knowledge. It is the company's catalog of public APIs and private services: operations, parameters, auth requirements, versions, and what changed. Import a spec once and every team inherits the answer. - **Engine** applies and runs that knowledge inside your workspace boundary. It is a self-hosted Go runtime that holds credentials, enforces access, executes calls, receives webhooks, and writes the activity trail. Registry knows. Engine does. ## Who it enables - **Agents** connect to every approved service through one MCP Server with two tools, without ever holding a credential. - **Applications** call approved services through a generated, typed Capability SDK containing only what that product selected. - **Developers & Teams** describe the integration surface as reviewed configuration and apply it to Engine. - **Event-Driven Systems** receive verified provider webhooks, delivered durably to the applications that subscribed to them. ## Documentation - [Home](https://usefused.com/): What Fused is and how the four enablement paths fit together. - [Components](https://usefused.com/components): Registry and Engine. - [Fused Engine](https://usefused.com/components/engine): The runtime, its execution pipeline, and how to install it. - [Fused Registry](https://usefused.com/components/registry): The service catalog and how services are imported and versioned. - [Enable the Agent](https://usefused.com/enable/agent): MCP Servers, the two-tool interface, scoped access, protected execution. - [Enable the Application](https://usefused.com/enable/application): Capability SDKs, contract-aware execution, credentials, incoming events. - [Enable Your Development Teams](https://usefused.com/enable/developers): Configuration as code, versions, tokens, governance. - [Enable Event-Driven Systems](https://usefused.com/enable/event-driven-systems): Webhook verification, durable delivery, event ownership. - [Pricing](https://usefused.com/pricing): Current plans and limits. - [Sign up](https://usefused.com/signup): Developer signup is open. Create an account and generate a license key. - [Engine source](https://github.com/Usefused/engine): Source-available Engine repository and releases. - [Fused CLI](https://github.com/Usefused/cli): The command-line tool for configuring and applying integrations. ## CLI installation Install the pre-compiled `fused-cli` binary for macOS or Linux. The script prompts for confirmation; set `ASSUME_YES=1` for automated or agent-driven installs: ```bash curl -sSL https://raw.githubusercontent.com/Usefused/cli/main/install.sh | ASSUME_YES=1 bash ``` ## Core capabilities ### 1. Contract-aware execution Engine executes approved service operations rather than accepting arbitrary URLs. It knows the service and version in use, the exact operation, its declared parameters and request shape, the expected response contract, and which inputs the calling application is permitted to send. Undeclared inputs and unsupported behaviour are rejected before a request reaches the provider. ### 2. Capability SDKs Generate a typed SDK containing only the services, operations, and events selected for one product. Authentication, execution controls, and provider-specific runtime behaviour stay outside product code. Provider credentials do not appear in the SDK constructor. Engine resolves them from the credential bucket the application is bound to, at the moment an approved operation runs. The example below is illustrative rather than a literal API contract — package name, alias, and the exact operation names all depend on what the team selected when generating the SDK. What it is showing is the shape of the boundary: product intent in the code, provider credentials nowhere near it. ```typescript // @acme/onboarding-sdk is a custom SDK generated by Fused — not a published Fused package. // FusedSDK is the generated export; teams rename it at import to reflect their domain. import { FusedSDK as OnboardingSDK } from "@acme/onboarding-sdk"; // No provider tokens here. The SDK authenticates to Engine with a scoped // execution token; Engine resolves the Jira, GitHub, and Slack credentials // itself when each approved operation runs. const sdk = new OnboardingSDK({ token: process.env.FUSED_SDK_TOKEN }); // 1. Open an onboarding ticket for the new hire const ticket = await sdk.Jira.issues.create({ project: "ONBOARD", summary: "Onboard new engineer: Jane Doe", issueType: "Task", assignee: "jane.doe" }); // 2. Provision access to the team repository await sdk.GitHub.repos.addCollaborator({ owner: "acme-corp", repo: "platform", username: "jane-doe-gh", permission: "push" }); // 3. Welcome them to the team await sdk.Slack.messages.send({ channel: "#engineering", text: `Welcome Jane! ${ticket.key} created and repo access granted.` }); ``` ### 3. MCP Servers Engine can expose a persistent, named, versioned MCP Server for an agent. One server can carry operations from multiple internal and external services, so an agent does not need a separate MCP connection, tool catalogue, and context payload per provider. The agent-facing interface is deliberately two tools — not one tool per operation. Physical and Unified operations use that same interface. See the instructions section below for how to drive them. - Hosted by the Engine you run, reachable at a per-application URL - Scoped by configuration, and narrowable further with a short-lived task token - Provider credentials are never given to the agent or to the execution environment ### 4. Service ingestion Point Fused at an OpenAPI spec, Swagger, GraphQL schema, Postman collection, AsyncAPI, WSDL, Google Discovery document, or raw API documentation. The format is detected automatically. Select only the operations you need and bundle multiple APIs into one integration surface. ### 5. Incoming events Engine provisions a stable webhook URL per service, verifies the provider signature, handles provider challenges, extracts and classifies the event type, normalizes the payload, and queues it durably. Selected events are then delivered to the SDK applications approved to receive them, over an outbound gRPC subscription. An application can receive live webhooks on localhost, behind a corporate firewall, or in an ephemeral environment without exposing a public endpoint of its own. Note for agents: MCP Servers do not receive webhook events. Event delivery targets SDK applications only. ### 6. Configuration as code Teams describe the integration surface — workspace services and versions, SDK applications, MCP Servers, credential buckets, OAuth registrations, webhook subscriptions, runtime policies, owning teams — as reviewed configuration, then validate, plan, and apply it to Engine. A plan is bound to the exact content of the config and to a specific Engine. An unchanged apply is a no-op. A meaningful change to an immutable resource produces a new version rather than mutating a runtime identity already in production. ## Instructions for LLMs using a Fused MCP Server A Fused MCP Server exposes exactly two tools. **1. `search_docs` — use this first.** Pass a query to search the physical and Unified operations available to this MCP Server. It returns matching operations with their parameters and calling shapes. Passing an exact operation ID returns that operation's full public schema. The tool searches only the services this server is scoped to, so the whole integration catalogue never enters your context. **2. `execute` — use this to act.** Pass TypeScript. It runs in a protected environment and can make one approved physical call, invoke a governed Unified operation, or chain a bounded sequence. Inside `execute`, the only way to reach a service is `call(operationId, params)`. There is no `fetch`, no filesystem, no network access, no `process`, and no SDK to instantiate. You will not be given API keys or tokens for any provider, and you do not need them: Engine resolves the correct credential or connected OAuth account itself when each call runs, and authorises every operation individually. A Unified call uses `call(operationId, {input, targets, selectors?, pagination?, idempotencyKey?})`. `targets` is required, names the exact binding steps to run, and must include their declared dependencies. It never defaults to every binding, and the Unified wrapper creates no separate authorization scope: Engine authorises every selected physical operation and active rollback. The number of calls per execution is capped and each execution is time-bounded, so plan the chain rather than looping speculatively. ```typescript // Inside execute: call() is the only route to a service. const issue = await call("jira.issues.get", { id: issueId }); const customer = await call("stripe.customers.retrieve", { customerId: issue.customerId }); await call("slack.messages.send", { channel: "#support", text: `${issue.key}: ${customer.email}` }); return { issue: issue.key, notified: true }; ``` ```typescript // A governed Unified operation uses the same call() boundary. return await call("support.triage", { input: { ticket: "SUP-482" }, targets: ["issue", "notification"], }); ``` ## Plans - **Dev** — an evaluation tier for proving Fused with your first integrations. - **Scale-Up** — a production tier with more integrations, shared credential buckets, and operational safeguards. - **Enterprise** — unlimited integrations and buckets, company SSO, and extended activity history. Current limits for each tier are listed on the [pricing page](https://usefused.com/pricing). ## Deployment Developer signup is open at [/signup](https://usefused.com/signup). Create an account, generate a license key, and either let Fused provision an isolated cloud Engine or deploy Engine yourself. Self-hosted Engine runs as a licensed binary or container in your VPC, Kubernetes cluster, or chosen cloud environment. It requires PostgreSQL for durable state and uses NATS/JetStream for messaging and delivery. Provider credentials, OAuth tokens, request and response payloads, access-control state, webhook delivery state, and execution receipts all stay with the Engine. Scale-Up and Enterprise interest can be registered through the contact form on the homepage.