{"slug":"business/INTEGRATION_MANAGER","title":"INTEGRATION MANAGER","section":"business","sectionLabel":"Business","status":"unclassified","type":"document","path":"business/INTEGRATION_MANAGER.mdx","bytes":2742,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n> **Tier C — Historical.** This document is a point-in-time snapshot preserved for reference. For current architecture, see [CANONICAL_PLATFORM_ARCHITECTURE.md](../architecture/CANONICAL_PLATFORM_ARCHITECTURE.md).\n\nStatus: CURRENT\nScope: Integration Manager platform capability\nCanonical Owner: Platform / Integration Manager\nLast Verified: 2026-07-11\nEvidence Basis: docs/CANON.md, docs/platform-specs/08-connector-framework.md, docs/platform-specs/24-integration-manager.md, docs/platform-specs/05-capability-fabric.md, docs/migrations/DE_SUPABASE_MIGRATION.md, docs/internal/operations/ENDPOINT_MAP.md, docs/internal/runbooks/connector-oauth-troubleshooting.md, docs/architecture/ONBOARDING_FLOW.md, Option B branch evidence, wrangler manifests\nSupersedes: none\nSuperseded By: none\n\n---\n\n## 1. WHAT INTEGRATION MANAGER IS\n\nIntegration Manager is the configuration center and adapter router for external system connection.\n\nIt does not own canonical truth.\nIt does not act as canonical transport layer except where explicitly authored.\nIt resolves capability routing for domain adapters such as:\n\n- Nango\n- MCP outbound adapters\n- Native REST connections\n- Webhook ingestion\n\nConnection lifecycle:\n\n- configuration and selection\n- tenancy and credential isolation\n- credential acquisition and refresh\n- transport selection\n- inbound/outbound event transformation\n- hydration into operational queue handling\n- downstream normalization path\n\n---\n\n## 2. INTEGRATION MANAGER AND HYDRATION\n\nHydration follows:\n\n- onboarding connection approval\n- initial data/event ingestion\n- transformation/normalization\n- canonical write through governed path\n- continuity state update\n\nHydration must not be documented as customer-zero-ready solely because onboarding routes or flows exist.\n\nFrontend hydration flow existence does not prove platform hydration, canonical write, or continuity initialization.\n\n---\n\n## 3. RETIRED-TECH LIMITS\n\nProduct-plane integration must not claim Supabase, Postgres, Vercel default hosting, or Cloud alternative persistence as canonical transport unless migration documentation shows completed replacement.\n\nIntegration Manager may reference legacy proof evidence for migration purposes only. Such reference must be labeled HISTORICAL.\n\n---\n\n## 4. DOCUMENTS THAT PRECEDE THIS\n\n- docs/platform-specs/24-integration-manager.md\n- docs/platform-specs/08-connector-framework.md\n- docs/platform-specs/05-capability-fabric.md\n- docs/architecture/ONBOARDING_FLOW.md\n- docs/archive/AUTH_CONNECTOR_INTEGRATION.md\n- docs/archive/TWO_LAYER_CONNECTION_MODEL.md\n- docs/archive/UNIVERSAL_CONNECTION_POOL_ARCHITECTURE.md\n\nWhen conflict arises between this document and those documents, this document is canonical.\n"}