> ## Documentation Index
> Fetch the complete documentation index at: https://bundleup.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Why BundleUp

> What it takes to build third-party integrations yourself, what BundleUp takes off your plate, and what stays in your hands.

Every integration looks small at first: register an OAuth app, redirect the user, call an API. The work shows up later, and it repeats for every provider you add.

## What building it yourself involves

For **each** provider, you need to:

1. **Run an OAuth flow.** Authorization URLs, state handling, PKCE for some providers, code exchange, error redirects, and provider quirks such as non-standard token responses or per-tenant URLs.
2. **Store tokens safely.** Access and refresh tokens are credentials to your customers’ data. They need encryption at rest, key management, and access controls.
3. **Keep tokens fresh.** Tokens expire on different schedules. Refreshes fail, race each other when two requests arrive at once, and rotate refresh tokens on some providers.
4. **Handle failure.** Timeouts, `429`s, `502`s and `503`s happen. You need to know which requests are safe to retry, how long to wait, and when to give up.
5. **Protect providers from yourself.** One noisy customer or a runaway job can exhaust a provider’s quota for everyone.
6. **See what happened.** When a customer says “the Slack sync is broken”, you need a log of every outbound call, its status and its latency.
7. **Normalize data** if you support several providers in the same category. Three Git hosts return three different shapes for “a repository”.

Then you do it again for the next provider.

## What BundleUp handles

| You’d otherwise build | With BundleUp |
| - | - |
| An OAuth flow per provider | One hosted [authorization flow](/docs/guides/auth/authorization-flow) for every provider. You get back a `connection_id`. |
| Token storage | Tokens are encrypted at rest and only decrypted in memory for the request that needs them. See [Security](/docs/platform/security). |
| Token refresh | Refreshed automatically when a request needs it, with concurrent refreshes for the same connection collapsed into one. |
| Retry logic | Idempotent requests are [retried](/docs/guides/proxy/retries) on timeouts and transient errors, with backoff. |
| Per-customer throttling | A [rate limit per connection](/docs/guides/proxy/rate-limits), so one account can’t starve the others. |
| Request logging | Every request [logged](/docs/guides/operations/logs) with status, duration and connection. |
| Data normalization | The [Unified API](/docs/guides/unified/overview) returns one shape per category. |
| An MCP gateway for agents | [MCP](/docs/guides/mcp/overview) access to providers’ own tools, scoped per user. |

## What you keep control of

**Your OAuth app.** You always bring your own OAuth credentials. Your users see *your* app name on the provider’s consent screen, and the provider’s rate limits, reviews and approvals are tied to *your* app, not to one shared with other BundleUp customers.

**Your scopes.** You choose exactly which permissions to request for each integration.

**Your data path.** The Proxy streams the provider’s response straight back to you. BundleUp doesn’t store request or response bodies.

**Your escape hatch.** Need something the Unified API doesn’t model? Drop down to the Proxy and call the provider’s API directly, using the same connection.

## When BundleUp is a good fit

* You connect to your **users’ accounts** in third-party tools (as opposed to only your own company account).
* You support, or plan to support, **more than one or two providers**.
* You want **AI agents** to act in users’ tools without handing tokens to the agent.
* You’d rather spend engineering time on your product than on OAuth plumbing.

## When it may not be

* You only call **one provider with your own company’s API key**, and never on behalf of users. A plain HTTP client is simpler.
* You need to keep every outbound call **inside your own network**. BundleUp is a hosted service that sits in the request path.

## Pricing in one line

You pay for requests, not for integrations, connections or users. The Free plan includes 250,000 requests a month. See [Pricing](/docs/platform/pricing).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.