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

# Connector Profiles

> The configuration for a connector, including its authentication and which actions and events are available.

<Frame>
  <img src="https://mintcdn.com/stackone-60/eqCjS7m4FAN_3XTx/images/concepts-connector-profiles.svg?fit=max&auto=format&n=eqCjS7m4FAN_3XTx&q=85&s=5dc31f95550cdff9e8e1b6b474ee336e" alt="Where Connector Profiles sit in StackOne: a profile lives in your project, configures a connector, and is what your end-users' linked accounts are authenticated against." style={{ width: "100%", maxWidth: "420px", margin: "1.5rem auto 2rem", display: "block" }} width="420" height="524" data-path="images/concepts-connector-profiles.svg" />
</Frame>

A **Connector Profile** holds the configuration for one connector in a project, including which of its actions and events are available to be used.

## What a profile holds

| Setting | Description |
| - | - |
| Authentication type | How end-users connect. The available methods depend on the connector, e.g. OAuth, API Key, or Basic Auth |
| Credentials | The authentication fields for that type (e.g. Client ID and Client Secret for OAuth) |
| Enabled actions | The [actions](/gateway/concepts/actions) [linked accounts](/gateway/concepts/linked-accounts) can call |
| Enabled events | The webhook events the connector can emit |
| Access | Whether the profile is **Shared** with the whole project or **Restricted** to granted members and groups |

You can configure more than one profile per connector, for example, an API Key profile for some accounts and an OAuth profile for others. The default profile decides which authentication fields appear in the Hub.

## Shared vs restricted

Every profile is either **Shared**, so anyone in the project who can link accounts may use it, or **Restricted**, so only the members and groups granted access can. A restricted profile is hidden from the linking flow for everyone else. Restricting controls use, not governance: project admins still view, edit, and delete the profile either way. See [Connector Profile Access](/secure/identity-and-access/roles-and-groups/connector-profile-access).

<CardGroup cols={2}>
  <Card title="Scoping Connectors" icon="sliders" href="/secure/scoping-connectors">
    Set up authentication, then choose which actions and events a profile exposes.
  </Card>

  <Card title="Use Your Own OAuth Apps" icon="key" href="/connect/managing-connectors/using-your-own-oauth-apps">
    Register your own OAuth app instead of using StackOne's shared credentials.
  </Card>

  <Card title="Connector Versioning" icon="code-branch" href="/connector-building/connector-versioning">
    Pin a profile to a connector version so its behavior stays fixed.
  </Card>

  <Card title="Managing Connectors" icon="gear" href="/connect/managing-connectors/overview">
    Configure, secure, and version the connectors your projects use.
  </Card>
</CardGroup>

## Connection issues behind a firewall

If a provider API or webhook endpoint is behind a firewall, allow inbound traffic from these StackOne IP addresses:

| IP address | Location |
| - | - |
| `35.175.11.132` | US East |
| `54.221.239.152` | US East |
| `52.5.1.25` | US East |
| `34.249.109.57` | Ireland |
| `46.51.152.189` | Ireland |
| `52.51.165.231` | Ireland |

Requests from your infrastructure to the StackOne API may pass through [AWS edge locations](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html). If your firewall restricts outbound traffic, allow HTTPS traffic to the AWS edge location ranges and the StackOne IP addresses above.

<Note>
  StackOne may add or remove IP addresses when regions or infrastructure change. Check this list when updating your firewall rules. Requests from StackOne use HTTPS with TLS 1.2 or later.
</Note>

<Accordion title="Systems only reachable over your VPN or inside your VPC">
  StackOne calls providers and remote MCP servers over the public internet, so it needs a public HTTPS address for the system. A private address such as `10.0.4.12` or `metabase.internal` can't be reached. With either setup below, StackOne can reach only the one service you publish, not the rest of your network. Either of these setups works today:

  * **Publish one endpoint behind your firewall.** Put the system's API behind your existing reverse proxy, API gateway, or web application firewall, and allow only the StackOne IP addresses above.
  * **Run an outbound tunnel.** Run a tunnel client such as [Cloudflare Tunnel](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/) or [ngrok](https://ngrok.com/docs) on a host inside your network. It only makes outbound connections and gives you a public HTTPS URL that forwards to one internal service. Restrict that URL to the StackOne IP addresses above.

  Then point StackOne at the public URL:

  * **A connector that asks for your instance URL**, such as a self-hosted Grafana or OpenSearch. Enter the public URL when linking the account.
  * **Your own MCP server**, if MCP connectors are enabled for your organization. **Project Admins** and **Project Members** add it from the connectors list with **Add MCP Connector**, entering the public URL as the **Remote MCP Server URL**.

  Keep authentication on the endpoint itself, such as the provider's own credentials or OAuth on your MCP server. An IP address list limits where requests come from, but StackOne's addresses are shared by every StackOne customer. A tunnel or proxy sign-in page meant for a person in a browser blocks StackOne's requests, so use IP rules at the tunnel instead.

  Expose only the service StackOne needs, never a whole subnet. Requests and responses pass through StackOne. If they must stay inside your network, contact your StackOne account team.
</Accordion>


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