Ship integrations inside your SaaS
Connect your users' apps, hand tools to your agents, and ship integration features — without building OAuth, vaults, or provider SDKs yourself.
You run a SaaS product — a support desk, a CRM, a vertical AI assistant — and your customers keep asking for the same things: "connect my Gmail", "let the AI file the Jira ticket", "give my agent access to our internal API".
Building that yourself means months of OAuth apps, token storage, per-provider clients, and an audit trail you invent later. Meanwhile the feature sits on the roadmap and deals stall on "does the AI actually do anything?"
You shouldn't have to become an integrations company to ship an AI product. Protobox handles connectors, OAuth, credential vault, tool execution, policies, and audit — so you can keep shipping your product, under your brand, in your UI.
The plan
Every embedding follows the same five steps:
Authenticate your backend. One workspace API key identifies your product (the principal). Your end-users are IDs you choose — Protobox never sees your user table.
import { ProtoboxSDK } from '@protoboxai/sdk';
const protobox = new ProtoboxSDK({ apiKey: process.env.PROTOBOX_API_KEY! });Scope to an end-user. protobox.entity(userId) binds connections and tool calls to one of your users. Credentials stay isolated per entity.
Connect apps. Hosted OAuth for the catalog, API keys for the rest, or register your own API as a private connector.
Execute. Hand tools to any LLM with a one-line adapter, serve them over a scoped MCP URL, or call them from background jobs.
Operate. Approvals for risky actions, webhooks for events, execution logs for audit.
Pick your recipe
Start with the customer ask that sold the deal, then layer trust and distribution:
| I want to… | Start here |
|---|---|
| Let my users connect Gmail, Slack, GitHub… inside my product | Connect your users' apps |
| Give my AI agent real tools (OpenAI, Anthropic, Vercel AI…) | Agent tool-calling |
| Turn my own API or code into agent tools | Your API as agent tools |
| Require human sign-off before risky actions run | Human-in-the-loop |
| See every execution, prove what happened, monitor health | Observability & audit |
| Keep everything under my brand — my consent screen, my vocabulary | White-label |
| Ship an MCP server my customers add to Claude or Cursor | Publish an MCP server |
| Give each user or conversation its own MCP endpoint | Per-user MCP sessions |
| Run tools from workflows and background jobs, react to events | Automations |
Start here: Connect your users' apps
The highest-impact first ship — a Connect Gmail button with hosted OAuth, per-user isolation, and clean offboarding.
Or run Quickstart
Get an API key and exercise the SDK path in minutes.
Success this week
The recipes share one running example: Acme, a customer-support SaaS. Swap in your domain; the shapes don't change.
With Protobox in place, Acme can:
- Put Connect Gmail / HubSpot in settings — each support seat's credentials, isolated.
- Let the in-product assistant search CRM and send reply as that seat, without writing provider clients.
- Pause refunds for human approval, then answer "what did the assistant do Tuesday?" from one execution log.
Failure you avoid
Without this path: tokens in your database, months of OAuth app review, agent calls as the wrong user, and no audit trail when a customer or compliance asks what the AI sent.
Provider tokens live in Protobox's vault and are applied server-side at execution time. They never transit your process or reach a model. See Error handling for the failure surface.
What stays yours
- Your UI. Connect buttons, tool pickers, and approval inboxes are your components calling your backend.
- Your brand. With BYO OAuth apps, consent screens carry your name; tool names speak your vocabulary.
- Your data model. End-users are opaque IDs. Protobox stores credentials and execution traces — not your customer records.
Two identity levels run through everything: your workspace (API key → principal) and your end-user (userId → actor). That split is what makes one Protobox workspace safely multi-tenant across all of your users.
Recipes use the @protoboxai/sdk 2.x surface, now public on npm. The 1.x line still on the registry is a different API — pin ^2.0.0.