Skip to main content
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.
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

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.

Scoping Connectors

Set up authentication, then choose which actions and events a profile exposes.

Use Your Own OAuth Apps

Register your own OAuth app instead of using StackOne’s shared credentials.

Connector Versioning

Pin a profile to a connector version so its behavior stays fixed.

Managing Connectors

Configure, secure, and version the connectors your projects use.

​
Connection issues behind a firewall

If a provider API or webhook endpoint is behind a firewall, allow inbound traffic from these StackOne IP addresses: Requests from your infrastructure to the StackOne API may pass through AWS edge locations. If your firewall restricts outbound traffic, allow HTTPS traffic to the AWS edge location ranges and the StackOne IP addresses above.
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.
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 or ngrok 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.