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, access mode, and selected tools.

Shipped Providers

Connect a Provider

1. Open the organization’s Integrations page.
2. Select the provider and read its setup instructions.
3. Create the narrowest provider credential that supports the intended work.
4. Choose read-only or full access.
5. Narrow the enabled tools when the provider supports tool selection.
6. Connect and allow Oblive to validate credentials and discover eligible tools.
7. Confirm the integration reports ready before assigning work that depends on it.

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.

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. Full mode adds 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 full-mode 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.

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 full access 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.

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.