What is Connector Namespace?
Per Microsoft, Connector Namespace is a fully managed integration service that hosts a catalog of prebuilt, reusable connectors for services such as SharePoint, Salesforce, SAP and Outlook. Applications can use these connectors through a consistent programming model instead of writing custom API client code, authentication flows, credential rotation, retry logic, pagination, and webhook subscriptions for each integration themselves.
According to current Microsoft documentation, the service is in public preview and is subject to the Supplemental Terms of Use for Microsoft Azure Previews. During preview, Connector Namespace is available only in Azure public regions, there is no SLA, and Microsoft does not currently recommend the service for production workloads. Per the documentation’s metadata, the announcement falls in the Build 2026 timeframe.
Connector Namespace targets compute services that don’t run on a workflow engine, such as Azure Functions, Container Apps or App Service. The service is deliberately separate from Azure Logic Apps: it does not use or change anything in Logic Apps workflows, and the connector gallery there continues to work independently.
Core Features
- Managed integration infrastructure: A connector namespace handles authentication and credential management, polling and webhook delivery, and retry, throttling and error-handling policies without custom implementation.
- Prebuilt connectors: Each connector abstracts the target service’s API, authentication protocol, pagination and retry behavior, exposing typed trigger and action operations.
- MCP server hosting: Connectors can be published as managed Model Context Protocol servers in a single step, or prebuilt MCP servers from a curated catalog can be deployed as hosted servers. In both cases the namespace handles hosting, tool definitions, lifecycle and credentials.
- Multi-language SDKs: Language-idiomatic SDKs are available for C# (Azure.Connectors.Sdk), Node.js (@azure/connectors) and Python (azure-connectors), with consistent telemetry and retry semantics; connectors can also be called directly over HTTP.
- Governance and security: Credentials stay within the connector namespace, which stores and rotates them; network access can be restricted via virtual network integration and private endpoints; and role-based access control (RBAC) governs who can create connections, register triggers, or invoke actions.
Typical Use Cases
Document processing: An Azure Function uses SharePoint connector operations to detect new or updated files, process them, and write results back.
External event monitoring: A container app receives events about new leads through a Salesforce connector trigger.
Productivity automation: A Node.js app reads and sends email through Outlook connector operations, reusing an existing connection.
AI and agentic workloads: A Python service calls connector actions to ground or enrich model output with data from business systems, or exposes connectors as MCP tools for AI agents.
Benefits
- No custom API client code needed for authentication, pagination, retry logic, or webhook subscriptions
- A pathway for compute services without a workflow engine (Functions, Container Apps, App Service, self-hosted environments) to use integrations
- Connectors can be exposed as MCP servers for AI agents and Copilot without extra infrastructure
- Central governance through RBAC, network restrictions, and managed credentials
- A consistent programming model across multiple languages and SDKs
Integration with innFactory
As a Microsoft Solutions Partner, innFactory helps you assess whether Connector Namespace fits your integration scenario, including the preview limitations around region availability, SLA, and connector coverage. We advise on the distinction from Azure Logic Apps and on connecting Connector Namespace to existing Azure Functions or Container Apps architectures, as well as to AI agents through MCP.
Contact us for a no-obligation consultation on Connector Namespace.
Typical Use Cases
Technical Specifications
Frequently Asked Questions
Is Connector Namespace generally available yet?
No. According to Microsoft's documentation, Connector Namespace is a preview capability subject to the Supplemental Terms of Use for Microsoft Azure Previews. There is no SLA during preview, and the vendor currently does not recommend the service for production workloads.
What is the difference between Connector Namespace and the connectors in Azure Logic Apps?
Per Microsoft, Connector Namespace is a separate integration pathway for compute services that don't run on a workflow engine. Connector namespaces don't require, use, or change anything in Azure Logic Apps; the connectors gallery in Logic Apps continues to work independently for workflows.
How do Connector Namespace and MCP servers relate to each other?
A connector namespace can convert any connector to a Model Context Protocol (MCP) server in a single step (managed), or add prebuilt MCP servers from a curated catalog (hosted). In both cases the namespace handles hosting, tool definitions, scaling and credentials, so AI agents such as Copilot or other MCP-aware clients can call the connected systems as tools.
How much does Connector Namespace cost?
Billing is consumption-based: per connector action, per trigger action, per tool call for managed and configurable MCP connectors, and per GB of data retention per month. Per Microsoft, per-unit rates are published on the Azure Logic Apps pricing page. Billing for hosted MCP servers is not yet enabled during preview; Microsoft provides notice before billing begins.
Note: All product information on this page has been compiled with care, but is provided without guarantee and may be outdated or incomplete. Cloud services evolve rapidly — features, pricing, SLAs, and availability change frequently. Authoritative and up-to-date information can only be found on the official product page of Azure (official documentation). This page does not represent an offer by Azure.
