Integrations overview

Integrations give Roomote more context inside a task: tickets, docs, monitoring, analytics, data systems, customer history, deployment state, and shared memory. This section does not list provider categories that have their own setup paths: communications providers, source-control providers, inference providers, and sandbox providers. Configure those from the provider-specific docs instead. Deployment operators can prevent every integration in this curated catalog from being configured or used by setting R_CURATED_INTEGRATIONS_DISABLED=true and restarting Roomote. Existing connections remain stored but inactive, so unsetting the value restores them. This policy does not affect the separate provider categories above or MCP servers defined on an environment.

​

Connection patterns

You will usually see one of these setup models:

• Admin connection once: an admin connects the integration for the deployment from Settings > Integrations
• Enable first, then teammates link accounts: an admin enables the integration, then each teammate links their own account from Personal Settings when they need it
• Workspace plus user identity: the deployment connects the integration, then individual users link their identity so Roomote can associate actions correctly

You can also ask Roomote to connect any integration in this catalog from a Session. Roomote starts the provider’s OAuth flow when the integration supports OAuth, opens the existing secure configuration form when an admin-managed key or certificate is required, and enables keyless integrations directly. The same admin, ownership, and deployment availability rules apply as in Settings. Credentials are never collected in chat. Roomote can list the full built-in catalog and current connection status without starting setup. A connection starts only after you ask to connect a provider. If you explicitly request a remote MCP server or direct API access instead, Roomote keeps that choice separate from the built-in integration path. A denied or pending authorization, unavailable integration, or permission failure is not silently bypassed with another connection method.

​

Manage available tools

Some connected integrations expose a Manage tools action in Settings > Integrations. Admins can use it to restrict the types of operations Roomote can make with the service. Use this as a coarse permissions system, for example allowing only read operations or restricting access to a certain type of entity. The list varies depending on the integration. Some integrations can only list tools after the first user links their account from Personal Settings.

​

Supported integrations

​

HTTP APIs without an MCP server

Deployment operators can configure HTTP integrations for approved HTTPS APIs. Sessions and sandbox agents use the same actor access rules, while Roomote keeps credentials server-side and attaches them to authorized requests. This opt-in feature does not change sandbox networking.

​

Custom MCP servers

Beyond the built-in catalog, you can connect your own MCP servers at two scopes:

• Deployment-wide, under Settings → Integrations → Custom MCP Servers: remote servers (with header or OAuth authentication, credentials held server-side) and local stdio servers, available to agents in every task.
• Per-environment, in the YAML view of the environment editor. See Environments. An environment entry with the same name as a deployment-wide server takes precedence in that environment.

Use deployment or user-linked integrations when the tool is broadly useful across teams. Use an environment-level MCP server when the tool only makes sense for one workspace, repository set, or self-hosted service. To use Roomote itself from an external OAuth-capable MCP client, connect the Roomote MCP. It can inspect Roomote and connected chat context, search and read tasks, list launch environments, launch or cancel tasks, and send follow-up messages. Its browser-issued credential does not grant general API or admin access.

​

A practical order

For most teams, this order works well:

1. the required providers: Comms, Source Control, Inference, and Sandboxes
2. one task-tracking integration, such as Linear, Jira, or Asana, if your team already works there
3. one monitoring or deployment integration, such as Sentry, Grafana, Railway, Better Stack, or Vercel, when investigations need it
4. one knowledge-base integration, such as Notion, to get tasks done directly from specs and runbooks
5. one data integration, such as Snowflake, Supabase, or Neon, when tasks need database or warehouse context
6. Supermemory when you want durable team context to carry across tasks and sessions

After each connection, run a small task that uses the new context. For example, ask Roomote to summarize a linked issue, inspect a monitoring alert, or explain which environment a support thread belongs to.