> ## 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.

# Integrations

> An integration is a provider configured for your workspace, using your own OAuth app and the scopes you choose.

An **integration** tells BundleUp how to connect to one provider on behalf of your workspace. It contains:

* **The provider type**, for example GitHub, Slack or HubSpot.
* **An identifier** you choose, such as `github`. You use it in code to say which integration a user is connecting.
* **Your OAuth app credentials**: the client ID and client secret from the app you registered with the provider.
* **Scopes**: the permissions BundleUp requests when a user connects.
* Any **provider-specific settings** the provider needs (for example, a subdomain).

An integration holds no end-user data. It’s the template that every [connection](/docs/concepts/connections) for that provider is created from.

## You bring your own OAuth app

BundleUp doesn’t provide shared OAuth apps. For every provider, you register an OAuth app (sometimes called a client, application or GitHub App) in the provider’s developer settings, and paste its credentials into BundleUp.

This means:

* Users see **your** product name and logo on the provider’s consent screen.
* The provider’s rate limits, app reviews and approvals apply to **your** app, not one shared with other companies.
* You decide exactly which scopes to request.

The provider needs to know where to send users after they approve. Set the app’s callback or redirect URL to BundleUp’s:

```text theme={null}
https://auth.bundleup.io/callback
```

The integration form in the dashboard shows this value. Step-by-step instructions are in [Setting up an integration](/docs/guides/integrations/creating).

## Identifier vs ID

Every integration has two names:

| Name | Example | Who chooses it | Where you see it |
| - | - | - | - |
| **Identifier** | `github` | You | The `integration_id` parameter of the authorization URL, and `integration_id` in the code-exchange response |
| **ID** | `cm1x9k2...` | BundleUp | The Platform API, webhook payloads (`integrationId`), request logs |

The identifier is unique within a workspace. Using the same identifiers in every environment’s workspace (dev, staging, production) means your code doesn’t change between them.

You can have more than one integration for the same provider, for example `github` for read-only access and `github-admin` with broader scopes, each with its own identifier.

## Changing an integration

You can update an integration’s credentials and scopes at any time from the dashboard.

* **New connections** use the updated settings.
* **Existing connections** keep the scopes the user originally granted. Providers don’t extend an existing grant. To give an existing connection new scopes, the user has to go through the authorization flow again.

## Deleting an integration

Deleting an integration also deletes **every connection** created through it. Requests using those connection IDs fail with `connection_invalid` afterwards. You receive an `integration.deleted` webhook.

## Which providers are supported

The list of providers, along with which ones support the [Unified API](/docs/guides/unified/overview) and [MCP](/docs/guides/mcp/overview), is on [bundleup.io/integrations](https://www.bundleup.io/integrations). Each provider’s page includes provider-specific setup notes.


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