SDK comparison

Fabric exposes three surfaces for building agentic applications. Choose based on what your code needs to control.

Quick comparison

When to use which

Use the Integrations SDK when...

• Your agent sends Slack messages, creates GitHub issues, or charges Stripe customers
• You need webhook handling with signature verification built-in
• You want permission gating (approval flows for destructive actions)
• You're building an agent that orchestrates across multiple SaaS tools

Example: A customer-support agent that reads Gmail threads, creates Linear issues, and posts updates to Slack.

Use the Portal SDK when...

• Your agent manages Fabric projects, documents, and workflows
• You want Claude Desktop or Cursor to control the portal
• You need RAG queries against workspace knowledge bases
• You're building a chatbot that lives inside the Fabric UI

Example: A product manager asking "Summarize all documents in the Q2 Planning project" via Claude Desktop.

Use the raw platform when...

• You're building a custom internal tool that needs direct database access
• You need to bypass permission checks (admin tools only)
• You're extending the platform itself (new tables, custom workflows)
• You need Temporal workflow definitions not exposed via the Portal SDK

Example: A custom reporting dashboard that joins data across multiple tables with complex aggregations.

Common production setups

Both SDKs together

Most production deployments use both SDKs:

// Integrations SDK: connect to external APIs
const fabric = createFabric({
  plugins: [slack({ botToken }), github({ token }), stripe({ apiKey })],
});

// Portal SDK: control the Fabric portal
// (Configured separately in Claude Desktop / Cursor)

The Portal SDK's fabric_chat_with_agent tool can trigger an agent that uses the Integrations SDK internally. This bridges both worlds: the user talks to the portal, and the portal's agent calls out to Slack, Stripe, etc.

Architecture pattern

┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│   Claude Desktop │────▶│  Portal SDK      │────▶│  Fabric Portal  │
│   or Cursor      │     │  (@fabric/mcp)   │     │  (UI + API)     │
└─────────────────┘     └──────────────────┘     └────────┬────────┘
                                                          │
                                    ┌─────────────────────┘
                                    ▼
                           ┌─────────────────┐
                           │  Agent Runtime  │
                           │  (Temporal)     │
                           └────────┬────────┘
                                    │
                    ┌───────────────┼───────────────┐
                    ▼               ▼               ▼
              ┌─────────┐    ┌─────────┐    ┌─────────┐
              │  Slack  │    │  GitHub │    │  Stripe │
              │  Plugin │    │  Plugin │    │  Plugin │
              └─────────┘    └─────────┘    └─────────┘

Migration path

Starting with one SDK and adding the other later is straightforward:

1. Start with Portal SDK: Get agents talking to the portal via MCP
2. Add Integrations SDK: When agents need to call external APIs
3. Bridge them: Use fabric_chat_with_agent to trigger integration-capable agents

Or reverse:

1. Start with Integrations SDK: Build automation scripts that call Slack/GitHub/Stripe
2. Add Portal SDK: Surface the same capabilities in Claude Desktop
3. Unify: Move orchestration logic into the portal's agent runtime

Feature matrix

Decision tree

Does your code need to call external SaaS APIs?
├── YES → Integrations SDK
│   └── Do you also need portal control?
│       ├── YES → Add Portal SDK
│       └── NO → Integrations SDK only
└── NO → Does your code need portal control?
    ├── YES → Portal SDK
    └── NO → Are you building internal platform extensions?
        ├── YES → Raw platform API
        └── NO → Reconsider scope