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

See AWS and Kubernetes for account verification, Kubernetes access and the separate production-release rule.

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.

In Insights → Calculation settings, activation and retention require explicit event choices. Enter the exact cohort-entry event and activation or return event from your project. Each person enters at their first retained entry event. Activation measures an outcome within the chosen 1–90 elapsed days; retention measures a return during elapsed day N through N+1. Calendar cohorts use the project’s timezone, and recent cohorts remain provisional until their observation window ends.

The reporting key needs Query Read and Project Read. Oblive requests aggregate counts with fixed parameterized PostHog queries, and retains no person profiles. Source retention and identity merges can change the cohort. Saving creates a new definition and collects its reports in the background; previous versions keep their original meaning.

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 Ask before writes and selects all 24 current tools; you can narrow the snapshot afterward. A sole accessible store is selected automatically. 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 can carry out explicit owner requests with full integration access. Growth tasks 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 can perform explicitly requested changes; Growth task writes retain their approval policy. 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.

PostHog project selection

Choose the US or EU region and the numeric project ID from PostHog project settings before saving the connection. Oblive verifies that project in the selected region. Both agent tools and built-in metrics use this project. A personal API key with access to several projects is supported; it does not expand the project selected in Oblive. Reporting requires Project Read and Query Read.

A connection supports one active PostHog project. Changing it invalidates prior connection authority and requires reporting discovery again before history is exposed under the new scope. The PostHog MCP project header prevents agent-driven project switching.