Managed Providers

Managed integrations are reconciled from a reviewed Git catalog. Provider name, documentation, setup guidance, categories, profile grants, authentication contract, and tool policy are catalog owned. Your organization owns connection state, credentials, permission mode, and selected tools.

Shipped Providers

Connect a Provider

1. Open the organization’s Integrations page.
2. Select the provider’s contextual card action to open the management sheet.
3. In Connection, read the setup instructions and create the narrowest provider credential that supports the intended work.
4. Keep Read-only, choose Ask before writes, or choose Autonomous, then submit the write-only credential or complete provider consent and configure any explicit resource scope.
5. Open Access to review or change the resulting permission mode.
6. Open Tools to review the initial snapshot. All tools currently eligible for the chosen mode are selected; use Select all eligible tools or individual choices to narrow it when the provider supports tool selection.
7. Confirm the integration reports ready before assigning work that depends on it.

Changing permission mode later selects all tools currently eligible for the target mode. Narrow the result afterward when needed. Provider tools introduced later are never added automatically.

Provider Notes

GitHub

Read-only mode uses GitHub’s provider-enforced read-only endpoint. Repository access and token scope remain owned by the connected GitHub identity. Engineering also receives scoped native Git for repository reads and, with a write-capable permission mode, ordinary branch delivery through the action lifecycle. See GitHub and Native Git.

Stripe

Use a restricted key with the minimum permissions. OAuth installation is not part of the current managed Stripe integration.

Exa and Firecrawl

Only reviewed tools are exposed. Newly added provider tools are not enabled automatically. Long server-side research is bounded by the configured tool timeout.

Apollo

Apollo uses provider authorization rather than an API key. Read-only mode requests profile and people-search access. The two write-capable modes add the reviewed people and company matching, enrichment, job posting, and result-reading scopes; it does not include contact mutation, CRM, lists, sequences, email, tasks, or purchasing. Some write-capable operations consume Apollo credits.

Do not use data obtained through Apollo MCP to train machine-learning models. Production Oblive deployments should complete Apollo’s MCP partnership registration before offering the integration to customers.

PostHog

Create a project-scoped personal API key with PostHog’s MCP Server preset. Oblive forces tools mode and limits the server to events, data schema, insights, dashboards, SQL, and persons. Read-only mode also asks PostHog to enforce a read-only session.

Crisp

A Crisp workspace owner must generate an MCP Server Token under Settings → Workspace Settings → Advanced configuration and copy it while it is visible. Paste it only into Oblive’s write-only credential form. Oblive stores the token encrypted and sends it only in the Bearer authorization header. Coordinate token regeneration with anyone using Crisp’s REST API because Crisp warns that the associated REST credentials may rotate too.

The frozen hosted-MCP allowlist contains 21 reviewed get_* and list_* reads. A write-capable permission mode adds five reviewed mutations: update_website_conversation_meta, change_website_conversation_state, update_website_people_profile, update_website_helpdesk_article, and update_website_helpdesk_category. Those mutations enter the action-approval lifecycle. Chat always receives only the read tools, even when the organization selects a write-capable permission mode.

Crisp’s hosted server does not currently advertise a send or reply tool, so agents cannot reply to conversations through this connector. Oblive does not fall back to Crisp’s REST API, and newly advertised MCP tools remain unavailable until reviewed.

Lemon Squeezy

Create an API key under Settings → API and copy it while it is visible. Lemon Squeezy separates test and live data, so connect a test-mode key first. Oblive does not infer the key’s mode. Paste the key only into the write-only form, validate it, and select one or more discovered stores. The key is stored encrypted and used only by the backend’s direct API provider; it never enters an agent process, workspace, command argument, or log.

Store scope is explicit. “Select all discovered stores” saves the current store IDs rather than a wildcard. A store created later remains unavailable until configuration is reopened and the new ID is selected.

Read-only access exposes 22 reviewed store, customer, catalog, order, subscription, invoice/item, and discount reads. Lists use explicit page numbers and never sweep all pages automatically. A write-capable permission mode adds only customer and checkout creation; both changes enter Oblive’s durable action lifecycle. The first connection defaults to Read-only and selects all 22 reads. Choosing Ask before writes or Autonomous selects all 24 current tools; either snapshot can be narrowed afterward. The returned checkout URL is the one intentional link result.

Refunds, subscription changes, usage records, licenses, files and downloads, webhooks, affiliates, checkout retrieval, and account-level user details are not exposed. There is no backend community MCP subprocess or fallback.

Growth and Support receive the connector. Chat is excluded because the read surface includes customer, order, and subscription data. Every future tool remains unavailable until separately reviewed.

Hostinger Email

Hostinger Mail handles individual mailbox work, including reviewed sends and private attachments. Hostinger Reach handles contacts, segments, profiles, and domain readiness; its current MCP surface does not draft, schedule, send, or analyze campaigns. Both connectors use provider authorization and are available to Growth and Support. See Hostinger Email.

Meta Ads

Meta Ads uses provider authorization for connection and Oblive’s fixed direct Marketing API tools for operational discovery and execution. The deployment administrator must configure one Meta-approved public OAuth client ID; there is no client secret. That client can authorize multiple organization integrations, and each organization retains a separate encrypted Meta token. Organization users do not create a separate developer app for each ad account. Local testing requires the Meta-specific public HTTPS callback; the generic managed-MCP callback continues to serve dynamically registered providers such as Apollo.

Chat is always read-only. Growth tasks with a write-capable permission mode can route reviewed changes through the action lifecycle. The direct provider is the default and does not depend on the hosted Ads MCP account rollout. hosted_mcp is available only as an explicit deployment rollback.

Private creative, catalog-feed, and hashed customer-audience files use Oblive’s companion path. The worker uploads directly to private object storage and the backend streams or chunks the verified bytes to Meta, so Meta never needs a public Oblive, localhost, CDN, or object-store URL. See Meta Ads for limits and deployment requirements.

X

Organic X uses a deployment OAuth 2.0 client with PKCE and Oblive’s fixed direct X API tools. It covers profiles, posts, replies, quotes, engagement, follows, Lists, Articles, analytics, and approved media uploads. Chat remains read-only; Growth task writes use the action lifecycle. See X.

X Ads

X Ads is a separate connector because the Ads API requires approved Ads API access and three-legged OAuth 1.0a. It does not reuse the organic X token. The direct provider covers accounts, funding, campaigns, line items, promoted posts, targeting, media libraries, audiences, native A/B tests, and analytics. New campaigns and line items are paused. Approved media uploads share the private staging path and use amplify_video for advertising video. See X Ads.

Upstash, MongoDB, and Google Analytics

These integrations use fixed read-only backend providers, explicit tool allowlists, and typed resource settings. Upstash is bounded by a database and key scope. MongoDB is bounded by an Atlas database plus collection and field allowlists and requires indexed winning query plans. Google Analytics separates Google consent from live-verified GA4 property selection. See Data Connectors.

Rotate or Disconnect

Credential changes invalidate reusable authorization state. After rotation, verify readiness and run a bounded read before resuming consequential workflows. Disconnect an account before attempting to replace it with a different identity when the provider requires identity continuity. These secondary actions live at the top of Connection, immediately below the management-sheet tabs; provider settings remain in the same section.