Skip to main content
Once a user has connected an account, you can call it three ways. All three share the same connection IDs, API keys, rate limits and logs, so this is a per-request decision, not a platform choice. Start at the top. If an AI agent is calling and the provider runs an MCP server, use MCP. Otherwise, if you need one data shape across several providers and the Unified API covers it, use the Unified API. In every other case, use the Proxy.

​
At a glance

​
Use the Proxy when

  • You integrate deeply with one provider and want its full API.
  • You need a write operation or a provider-specific feature the Unified API doesn’t model.
  • You already have code that calls the provider directly. Point it at proxy.bundleup.io, add two headers, and delete your token handling.
The Proxy is a transparent pass-through: the provider’s paths, query parameters, bodies and responses, unchanged. See Proxy overview.

​
Use the Unified API when

  • You want a feature to work across every provider in a category (for example, “import issues from whichever tracker the customer uses”) without writing per-provider code.
  • The data you need is covered by the categories: account, chat, git, tasks, helpdesk, CRM, drive and calendar.
You can always fetch the provider’s original payload alongside the normalized one with include_raw=true. See Unified API overview.

​
Use MCP when

  • An AI agent needs to act in a user’s account, and the provider runs its own MCP server.
  • You want the provider’s tools (names, descriptions, schemas) as-is, kept up to date by the provider.
BundleUp keeps the token away from the agent and picks the right account by connection ID. See MCP overview.

​
Mixing them

Because all three use the same connection, mixing them is normal:
  • A sync job reads tasks through the Unified API, then posts a provider-specific comment through the Proxy.
  • An agent uses MCP for most tools, while your backend uses the Proxy for a scheduled export from the same account.
Every request, whichever surface it uses, shows up in the same request log and counts toward the same rate limit for that connection.