GitHub Copilot is moving to usage-based billing
Instead of counting premium requests, every Copilot plan will include a monthly allotment of GitHub AI Credits, with the option for paid plans to purchase additional usage. Usage will be calculated based on token consumption, including input, output, and cached tokens, using the listed API rates for each model. This change aligns Copilot pricing with actual usage and is an important step toward a sustainable, reliable Copilot business and experience for all users. Learn more here and access partner resources here. APAC Office hours link – May 6, 7:00 PM — 8:00 PM PDT EMEA/AMER Office hours link – May 7, 8:00 AM — 9:00 AM PDT
Moving the Logic Apps Designer Forward
Today, we're excited to announce a major redesign of the Azure Logic Apps designer experience, now entering Public Preview for Standard workflows. While these improvements are currently Standard-only, our vision is to quickly extend them across all Logic Apps surfaces and SKUs. ⚠️ Important: As this is a Public Preview release, we recommend using these features for development and testing workflows rather than production workloads. We're actively stabilizing the experience based on your feedback. This Is Just the Beginning This is not us declaring victory and moving on. This is Phase I of a multi-phase journey, and I'm committed to sharing our progress through regular blog posts as we continue iterating. More importantly, we want to hear from you. Your feedback drives these improvements, and it will continue to shape what comes next. This redesign comes from listening to you—our customers—watching how you actually work, and adapting the designer to better fit your workflows. We've seen the pain points, heard the frustrations, and we're addressing them systematically. Our Roadmap: Three Phases Phase I: Perfecting the Development Loop (What we're releasing today) We're focused on making it cleaner and faster to edit your workflow, test it, and see the results. The development loop should feel effortless, not cumbersome. Phase II: Reimagining the Canvas Next, we'll rethink how the canvas works—introducing new shortcuts and workflows that make modifications easier and more intuitive. Phase III: Unified Experiences Across All Surfaces We'll ensure VS Code, Consumption, and Standard all deliver similarly powerful flows, regardless of where you're working. Beyond these phases, we have several standalone improvements planned: a better search experience, streamlined connection creation and management, and removing unnecessary overhead when creating new workflows. We're also tackling fundamental questions that shouldn't be barriers: What do stateful and stateless mean? Why can't you switch between them? Why do you have to decide upfront if something is an agent? You shouldn't. We're working toward making these decisions dynamic—something you can change directly in the designer as you build, not rigid choices you're locked into at creation time. We want to make it easier to add agentic capabilities to any workflow, whenever you need them. What's New in Phase I Let me walk you through what we're shipping at Ignite. Faster Onboarding: Get to Building Sooner We're removing friction from the very beginning. When you create a new workflow, you'll get to the designer before having to choose stateful, stateless, or agentic. Eventually, we want to eliminate that upfront choice entirely—making it a decision you can defer until after your workflow is created. This one still needs a bit more work, but it's coming soon. One View to Rule Them All We've removed the side panel. Workflows now exist in a single, unified view with all the tooling you need. No more context switching. You can easily hop between run history, code view, or visual editor, and change your settings inline—all without leaving your workflow. Draft Mode: Auto-Save Without the Risk Here's one of our biggest changes: draft mode with auto-save. We know the best practice is to edit locally in VS Code, store workflows in GitHub, and deploy properly to keep editing separate from production. But we also know that's not always possible or practical for everyone. It sucks to get your workflow into the perfect state, then lose everything if something goes wrong before you hit save. Now your workflow auto-saves every 10 seconds in draft mode. If you refresh the window, you're right back where you were—but your changes aren't live in production. There's now a separate Publish action that promotes your draft to production. This means you can work, test your workflow against the draft using the designer tools, verify everything works, and then publish to production—even when editing directly on the resource. Another benefit: draft saves won't restart your app. Your app keeps running. Restarts only happen when you publish. Smarter, Faster Search We've reorganized how browsing works—no more getting dropped into an endless list of connectors. You now get proper guidance as you explore and can search directly for what you need. Even better, we're moving search to the backend in the coming weeks, which will eliminate the need to download information about thousands of connectors upfront and deliver instant results. Our goal: no search should ever feel slow. Document Your Workflows with Notes You can now add sticky notes anywhere in your workflow. Drop a post-it note, add markdown (yes, even YouTube videos), and document your logic right on the canvas. We have plans to improve this with node anchoring and better stability features, but for now, you can visualize and explain your workflows more clearly than ever. Unified Monitoring and Run History Making the development loop smoother means keeping everything in one place. Your run history now lives on the same page as your designer. Switch between runs without waiting for full blade reloads. We've also added the ability to view both draft and published runs—a powerful feature that lets you test and validate your changes before they go live. We know there's a balance between developer and operator personas. Developers need quick iteration and testing capabilities, while operators need reliable monitoring and production visibility. This unified view serves both: developers can test draft runs and iterate quickly, while the clear separation between draft and published runs ensures operators maintain full visibility into what's actually running in production. New Timeline View for Better Debugging We experimented with a timeline concept in Agentic Apps to explain handoff—Logic Apps' first foray into cyclic graphs. But it was confusing and didn't work well with other Logic App types. We've refined it. On the left-hand side, you'll now see a hierarchical view of every action your Logic App ran, in execution order. This makes navigation and debugging dramatically easier when you're trying to understand exactly what happened during a run. What's Next This is Phase I. We're shipping these improvements, but we're not stopping here. As we move into Phase II and beyond, I'll continue sharing updates through blog posts like this one. How to Share Your Feedback We're actively listening and want to hear from you: Use the feedback button in the Azure Portal designer Join the discussion in GitHub/Community Forum – https://github.com/Azure/LogicAppsUX Comment below with your thoughts and suggestions Your input directly shapes our roadmap and priorities. Keep the feedback coming. It's what drives these changes, and it's what will shape the future of Azure Logic Apps. Let's build something great together.Write Logic Apps in C#: introducing the Logic Apps Standard SDK
The workflow you always wished you could write in code If you build on Logic Apps Standard, you already know the deal: the runtime is excellent at the unglamorous parts of integration - connecting to systems, retrying, scaling, keeping run history you can actually debug. What you sometimes wanted was a different front door. You're a .NET developer. You live in C#, source control, and pull requests. And for a long time, authoring a workflow meant leaving all of that behind for a visual designer and a JSON file. That's the gap the new Logic Apps Standard SDK closes. It lets you define Logic Apps Standard workflows in code - strongly typed, IntelliSense-guided C# - without giving up a single thing the runtime already does for you. What is the Logic Apps Standard SDK? The Logic Apps Standard SDK (Microsoft.Azure.Workflows.Sdk) is a NuGet package that gives you a fluent, code-first way to build workflow definitions in C#. Instead of dragging actions onto a canvas, you compose a workflow with method chaining: a trigger, then the actions that follow it, all the way to a response. Worth saying clearly, because people ask: this is a new way to define workflows - not a new runtime. The workflows you write with the SDK compile down to the same definitions and run on the same Logic Apps Standard runtime you use today. Same connectors. Same hosting. Same rich run history and monitoring. You're changing the authoring experience, not the engine underneath it. Why this matters for developers When your workflow lives in C#, it behaves like the rest of your code. A few things fall out of that almost for free: Type safety and IntelliSense - connector operations, triggers, and outputs are discoverable as you type, and the compiler catches mistakes before you run anything. Real source control and reviews - workflows diff like code, get reviewed in pull requests, and version alongside the services they orchestrate. Familiar tooling - refactor, debug with F5, and lean on the .NET ecosystem you already know. Extensibility on your terms — Compose your workflow declaratively with the fluent builder, then drop into plain imperative C# wherever a step needs logic that might be too complex to implement declaratively - loops, branching, a call into your own library, all encapsulated in a step of your workflow - without leaving the file or the language. And it isn't limited to one style of work. The SDK covers both enterprise integration workflows - the connect-systems-and-move-data scenarios Logic Apps is known for - and agentic workflows, where a conversational or autonomous AI agent drives the steps. Both are first-class in the same SDK, built from the same building blocks. There's one more angle worth calling out, because it's becoming hard to ignore: coding agents are simply better at writing imperative code than declarative JSON. And the reason is the same set of guardrails that helps you. Strong typing and a compilation step mean the code an agent produces is syntactically correct out of the gate — the type system and the compiler do the checking, so you don't have to. Layer unit tests on top and you've covered north of 90% of what matters; what's left is integration testing. Getting an LLM to the same level of accuracy against declarative JSON means building dedicated tooling to stand in for everything the compiler gives you for free. With code-first workflows, those guardrails are just there — which makes this a natural fit for an agent-assisted way of building. Getting started Everything here lives in the Logic Apps extension for VS Code. You'll want the Logic Apps Standard VS Code extension version 5.961.10 or later, which includes all the components you need to create code first workflows. Beyond that, the prerequisites are the ones you'd expect - VS Code with the Logic Apps extension, an Azure subscription you can create resources in, and a working comfort with C# and .NET. From a clean start, you're a handful of steps from a running workflow: Create the workspace — launch the Logic Apps extension and choose Create new Logic Apps workspace. Pick a folder, name the workspace and project, and when prompted for the workflow type, choose Logic Apps codeful - that's the code-first option that uses the SDK. Pick a workflow kind - name your first workflow and choose how it runs: Stateful, Autonomous agents (Preview), or Conversational agents (Preview). The agent options are where the agentic scenarios live. Enable connectors - when prompted, select Use connectors from Azure, choose your subscription and resource group, and pick Connection Keys for authentication. Managed identity is still in development, so connection keys are the way in for now. Find your way around - the project opens with Program.cs, which builds and starts the host, plus a workflow file (like workflow1.cs) where your trigger and actions are defined. The SDK compiles those definitions and runs them on the Logic Apps runtime. Run it - press F5 (or right-click Program.cs and pick Overview). The runtime starts locally and an overview page opens where you can fire triggers, watch run history, and inspect inputs and outputs. That last part is worth dwelling on: run history for SDK workflows uses the same rich visual view as designer-built ones. You author in code, but you monitor and troubleshoot exactly as you always have. A look at the capabilities Connectors and triggers Every workflow starts with a trigger and runs a series of actions. The SDK exposes both through two entry points - WorkflowTriggers and WorkflowActions - each split into BuiltIn and Managed. Built-in triggers and actions run directly in the runtime: HTTP request, recurrence, and the conversational agent trigger; actions like Compose, HTTP, Response, and custom code. Managed connectors give you the full Logic Apps connector catalog - Service Bus, SharePoint, SQL, and hundreds more - typed and ready to call. The managed surface is generated from the same connector definitions the designer uses, so the operations you know are right there: // Built-in trigger var trigger = WorkflowTriggers.BuiltIn.CreateHttpTrigger(); // Managed connector action — full catalog, strongly typed var getItems = WorkflowActions.Managed .Sharepointonline("sharepoint") .GetItems( dataset: () => "https://contoso.sharepoint.com", table: () => "orders-list-id") .WithName("GetOrders"); The fluent API streamlines the definition This is where it comes together. You compose a workflow by chaining operations with .Then(...). The shape of your code mirrors the shape of your workflow - read it top to bottom and you read the execution path. trigger .Then(validateOrder) .Then(getOrders) .Then(sendResponse); Control flow is part of the same fluent model. Built-in structures like Condition (if/else) and ForEach - along with Switch, Until, Scope, and Terminate - are just actions you chain in, each taking a small factory for the branch or loop body: var checkTotal = WorkflowActions.BuiltIn.Control.Condition( expression: () => order.Total > 1000, trueBranch: () => requireApproval, falseBranch: () => autoApprove ).WithName("CheckOrderValue"); And ForEach takes the collection to iterate and a factory that builds the body for each item: var processLines = WorkflowActions.BuiltIn.Control.ForEach( items: () => order.LineItems, actions: (item) => new WorkflowBuiltInActions() .Compose(inputs: () => $"Line: {item}").WithName("HandleLine") ).WithName("ProcessLineItems"); Need parallel branches that fan back in? The same Then pattern handles branching and join - no JSON wiring, no run-after blocks to hand-edit. Extending workflows with custom code Some logic doesn't belong in a connector or an expression - it's just code. The CustomCode action lets you drop a real C# method into the middle of a workflow. It receives a WorkflowContext, so you can read the trigger payload or any earlier action's results and return a strongly typed value the next step can use: var enrich = WorkflowActions.BuiltIn.CustomCode<string>(async (context) => { var trigger = await context.GetTriggerResults(); var order = await context.GetActionResults("GetOrders"); // your logic, your libraries, your types return "enriched"; }).WithName("EnrichOrder"); That's the escape hatch that keeps you in flow: when a step needs custom transformation, validation, or a call into your own libraries, you write a method instead of bending an expression to do something it was never meant to. Handling failures: try/catch with run-after Real workflows have to deal with things going wrong, and the SDK gives you the same try/catch shape Logic Apps has always had - expressed in code. The .Then(...) overload takes a FlowStatus[] run-after condition, so a handler runs only when the step before it ends in a status you name. Wrap the risky work in a Scope (your try), then chain a handler that runs after it Failed or TimedOut (your catch): var tryProcess = WorkflowActions.BuiltIn.Control.Scope(() => callPaymentApi.Then(saveOrder) ).WithName("ProcessPayment"); var handleFailure = WorkflowActions.BuiltIn .Compose(inputs: () => "Payment failed — compensating") .WithName("HandleFailure"); trigger .Then(tryProcess) .Then(handleFailure, runAfter: new[] { FlowStatus.Failed, FlowStatus.TimedOut }); The status set is the whole vocabulary: Succeeded, Failed, Skipped, and TimedOut. Combine them however a step needs - a cleanup action that should run no matter what can list every status; a finally is just the union. The same idea scales to fan-in. When several parallel branches converge, the per-predecessor RunAfter overload lets the join wait on each branch independently - so you can require some to succeed and tolerate others failing: leftChain .Join(rightChain) .Then(merge, runAfter: new[] { new RunAfter(leftChain, FlowStatus.Succeeded), new RunAfter(rightChain, FlowStatus.Succeeded), }); Putting it together Here's a small but complete shape - an HTTP-triggered order workflow that validates input, branches on order value, loops over line items, runs custom code, and replies. The core steps live in a Scope so a single failure handler can catch anything that goes wrong, and a clean reply only runs when the work succeeds. Notice it's all one readable chain: namespace LogicApps { using Microsoft.Azure.Workflows.Sdk; using Microsoft.Azure.Workflows.Sdk.Connectors.Msnweather; using System.Net; public class OrderWorkflow : IWorkflowProvider { /// <summary> /// Gets the HTTP request/response workflow definition. /// </summary> public FlowDefinition[] GetWorkflows() { // --- Trigger ---------------------------------------------------- var trigger = WorkflowTriggers.BuiltIn.CreateHttpTrigger(); // --- Managed connector action (full catalog, strongly typed) ---- // Reused verbatim from the confirmed stateful1.cs pattern. var getWeather = WorkflowActions.Managed.Msnweather("msnweather").CurrentWeather( location: () => "98058", units: () => unitsInput.Imperial).WithName("GetWeather"); // --- Custom code: real C# in the middle of the workflow --------- var enrich = WorkflowActions.BuiltIn.CustomCode<string>(async (context) => { var triggerResults = await context.GetTriggerResults(); var weather = await context.GetActionResults("GetWeather"); // your logic, your libraries, your types return "enriched"; }).WithName("EnrichOrder"); // --- ForEach over a collection (control flow via .Control) ------- var processLines = WorkflowActions.BuiltIn.Control.ForEach( items: () => trigger.TriggerOutput.Body["lineItems"], actions: (item) => WorkflowActions.BuiltIn .Compose(inputs: () => $"Line: {item}").WithName("HandleLine") ).WithName("ProcessLineItems"); // --- Condition (if/else) (control flow via .Control) ------------ var checkTotal = WorkflowActions.BuiltIn.Control.Condition( expression: () => true, trueBranch: () => processLines, falseBranch: () => WorkflowActions.BuiltIn .Compose(inputs: () => "Auto-approved").WithName("AutoApprove") ).WithName("CheckOrderValue"); // --- Scope groups the core steps so one handler catches failures - var processOrder = WorkflowActions.BuiltIn.Control.Scope(() => checkTotal .Then(getWeather) .Then(enrich) ).WithName("ProcessOrder"); // --- Responses -------------------------------------------------- var ok = WorkflowActions.BuiltIn.Response( responseBody: () => "Order processed").WithName("Reply"); var failed = WorkflowActions.BuiltIn.Response( statusCode: () => HttpStatusCode.InternalServerError, responseBody: () => "Order failed").WithName("ReplyFailed"); // --- Assemble --------------------------------------------------- // Happy path runs after the Scope Succeeded; the handler runs after // Failed or TimedOut. trigger .Then(processOrder) .Then(ok, runAfter: new[] { FlowStatus.Succeeded }) .Then(failed, runAfter: new[] { FlowStatus.Failed, FlowStatus.TimedOut }); return new[] { WorkflowFactory.CreateStatefulWorkflow("OrderWorkflow", trigger) }; } } } That last stretch is the best-practice shape in miniature: the happy-path Reply runs only after the Scope Succeeded, while a separate handler catches Failed or TimedOut and returns a 500 - no exception plumbing, just run-after conditions. You implement IWorkflowProvider, hand your trigger graph to WorkflowFactory as a stateful, stateless, or agent workflow, and the host registers it. Run it with F5 and the Logic Apps runtime starts locally - same as any Standard project. Before you build: preview realities I'd rather you go in clear-eyed. While the SDK is in public preview, keep these in mind: Service Provider connectors aren't supported yet - that connector type is coming in a future release. Dynamic schemas aren't supported - support is planned. Custom code supports callback methods only - inline lambdas aren't available in this version. Define and name actions before referencing them - name an action before using it as a dependency elsewhere. Managed identity authentication is in development - use connection keys for connectors in the meantime. Try it, and tell us what you think If you've ever wanted your workflows to live where the rest of your code lives - in C#, in source control, in your pull requests - this is for you. Install the Logic Apps extension for VS Code, create a Logic Apps codeful project, and build your first workflow in code. This is a preview, which means your feedback genuinely shapes where it goes - which capabilities come next, where the rough edges are. Bring issues, feature requests and feedback to our GitHub page. I read it. Let's make code-first workflows something you actually want to use.New AI gateway capabilities in Azure API Management
Multi-model, multi-protocol AI applications are quickly becoming the norm. Teams are mixing OpenAI, Anthropic, and Vertex AI models, exposing tools through MCP, and wiring agents together with A2A. As that surface grows, so does the work of keeping it secure, observable, and consistent. Our ongoing strategy for the AI gateway capabilities in Azure API Management centers on that problem: providing one place to manage models, MCP tools, and agents, no matter which provider or protocol is behind them. The updates below are the latest steps in that direction. Unified Model API (preview) The headline change in this release: the Unified Model API lets clients speak one API format — OpenAI Chat Completions — while API Management transforms requests to the backend provider, whether that's a model using OpenAI Chat Completions or Anthropic Messages API. By centralizing model access behind a single API layer, you can: Standardize on a single API format for clients, independently from the formats used by backend models. Unify observability, security, and governance with policies that apply across model providers. Configure failover across model providers. Decouple client-facing model names from backend model names using aliases. Learn more about the unified model API. Model aliases Model aliases give clients a stable, provider-neutral name to use when calling a model. By assigning an alias like gpt or claude-sonnet, you decouple the client-facing model name from the actual backend deployment. That makes a few common operations a lot easier: Upgrading a model. Update the alias target to point at a new version — no client code changes required. A/B tests. Shift traffic between backends behind the same alias using API Management's load balancing capabilities. Vendor swaps. Replace one provider with another without touching application code. Model discovery Developers can discover available models by calling the /models endpoint of the Unified Model API. API Management returns the list of model aliases, so apps and tools can adapt to what the platform team has published — without out-of-band documentation. Anthropic and Vertex AI models (GA) AI gateway policies and observability now work with Anthropic and Google Vertex AI models, alongside the providers we already support. You can: Apply runtime policies such as content safety, token limits, and semantic caching to Anthropic and Vertex AI traffic. Collect logs, traces, and metrics for these models in the same place as the rest of your AI traffic. If you're running a multi-provider setup, you no longer need a separate governance story for each vendor. Learn more about AI gateway capabilities in API Management. Anthropic API operations in Microsoft Foundry import When you import a Microsoft Foundry resource as an API in Azure API Management, the import now creates operations for Anthropic APIs alongside the existing model APIs. In a few clicks, you can stand up an API that mediates traffic to Foundry models using either the OpenAI or Anthropic API format — no manual operation definitions needed — and then apply the same policies, security, and observability you use for the rest of your AI traffic. Learn more about Microsoft Foundry import. Token metrics for additional token types (preview) Token tracking used to stop at prompt, completion, and total tokens. Modern models add cached, reasoning, and thinking tokens, which can make up a significant share of token consumption, cost, and latency. API Management now logs metrics for these additional token types into Application Insights, across API formats (OpenAI Chat Completions, OpenAI Responses, and Anthropic Messages API) and providers (Microsoft Foundry, OpenAI, Amazon Bedrock, Google Vertex AI, and others). With richer signals, your cost dashboards, budget alerts, and capacity planning can actually reflect how today's models behave. Learn more about token metrics. Content safety for MCP and A2A (GA) The llm-content-safety policy now covers MCP and A2A traffic in addition to LLM traffic. That includes MCP tool-call arguments, MCP response text, and A2A payloads. A couple of related improvements: llm-content-safety can now be configured directly as an outbound policy. Two new attributes — window-size and window-overlap-size — let you tune how messages exceeding the Azure Content Safety limit of 10,000 characters are chunked and forwarded for validation, balancing detection sensitivity with Azure Content Safety call volume. The result is one consistent safety policy across LLM, MCP, and A2A flows instead of stitching together custom filters per protocol. Learn more about the content safety policy. A2A APIs (GA) Support for Agent-to-Agent (A2A) APIs in API Management is now generally available. Agent APIs can now be governed with the same policies, identity, and observability you use for the rest of your APIs. What you can do with A2A APIs in API Management: Mediate JSON-RPC runtime operations to your agent backend with full policy support — including the content safety improvements above. Expose and manage agent cards, automatically transformed by API Management to represent the managed agent API. Log traces to Application Insights using OpenTelemetry GenAI semantic conventions for deep correlation between API and agent execution traces. What's new in GA, on top of the preview: Available in classic tiers, in addition to v2 tiers — bring A2A governance to existing API Management resources without migrating tiers. Richer diagnostic logging for A2A APIs, giving more actionable telemetry for monitoring and troubleshooting agent traffic. Learn more about A2A support in API Management. Related: Bring Your Own Model in Foundry Agent Service (GA) Last month, Bring Your Own Model (BYOM) in Foundry Agent Service went GA. BYOM lets enterprise teams route Foundry agent model calls through their own infrastructure — typically for compliance, governance, or to reuse an existing model gateway. This pairs naturally with the AI gateway capabilities in Azure API Management. Put API Management in front of your models, apply the policies and observability described above, and have Foundry agents call through it — getting consistent governance for both your direct AI traffic and your agent workloads. Get started Together, these updates make Azure API Management a more complete AI gateway: consistent governance, security, and observability across models from various providers, MCP tools, and agent interactions. Some of these features are still rolling out. They will first become available in v2 tiers of API Management and in the AI release channel for classic tiers, then continue rolling out to the rest of classic tier resources over the following weeks. Get started with the unified model API or explore the AI gateway capabilities in API Management.Azure Connector Namespaces: managed integration for any Azure compute
The integration tax nobody budgets for It is always a simple task on paper: connect apps to the systems the business actually runs on — SharePoint, Salesforce, SAP, Outlook — and get back to building features. What gets in the way is rarely the business logic. It's the plumbing. You write a custom API client for each service. You wire up OAuth flows and then babysit token refresh. You add retry policies, handle throttling, page through results, and stand up webhook subscriptions you now have to keep alive. None of that is the feature. All of it is on you. Historically, if you wanted that work done for you, the answer was a workflow engine. That's great when you want a workflow — but a lot of apps just want to call an action or react to an event from code they already have, running on the compute they already use. That's the gap Azure Connector Namespace fills. What is Azure Connector Namespace? Azure Connector Namespace is a fully managed integration service that hosts a catalog of prebuilt, reusable connectors and MCP servers that your apps consume through a consistent programming model. Instead of writing and operating a client for each system, you create a connection once and call typed operations from your code. The namespace handles authentication, credential rotation, polling, webhook delivery, retries, throttling, and error handling on your behalf. Worth saying clearly, because people ask: a connector namespace is independent of Azure Logic Apps. It doesn't require, use, or change anything in Logic Apps, and the Logic Apps connectors gallery keeps working separately for workflows. Connector Namespace is the integration path for compute that doesn't run on a workflow engine — your Functions, Container Apps, App Service, and self-hosted services. Each connector exposes three kinds of surface through one shared connection model: Triggers — event subscriptions your app registers (a new email arrives, a record updates, a file lands in a folder). Actions — operations your app calls (send a message, read a row, upload a file). AI agent tools — the same operations, exposed to agents and Copilot through MCP servers. You call all of it from strongly typed SDKs for C# (Azure.Connectors.Sdk), Node.js (@azure/connectors), and Python (azure-connectors) — or over plain HTTP if a typed SDK isn't a fit. The building blocks Five concepts and you have the whole model: Concept What it is Connector namespace The Azure resource that hosts the connector runtime — loads and runs operations, maintains connection state and credentials, polls source systems, dispatches webhook events, and applies retry and diagnostic policies. Create it from the Azure portal, ARM/Bicep, or the CLI. Connector A prebuilt component for one service (SharePoint, Salesforce, SAP, Outlook). It abstracts the underlying API, auth protocol, pagination, and retry behavior so your code stays on business logic. Connection An authenticated, configured binding to an account or tenant. Connections are reusable — multiple apps and connectors can share one. Auth types: OAuth, API key, and Basic. MCP server A first-class resource that exposes tools to AI agents over the Model Context Protocol. Comes in managed and hosted flavors (more below). Connector SDKs Strongly typed clients for C#, Node.js, and Python that share the same catalog, connection model, telemetry, and retry semantics. Or call connectors over HTTP. What you can actually do with it The point of all this is the scenarios it unlocks. A few that show the range: Scenario What it looks like Process documents and content An Azure Function uses SharePoint connector operations to detect new or updated files, processes them, and writes results back to SharePoint. Monitor events from external services An Azure Container App uses a Salesforce trigger to receive events about new leads as they're created. Automate productivity A Node.js app uses Outlook operations to read and send email — reusing a connection another app already owns. Ground AI and agentic workloads A Python service calls connector actions to enrich model output with data from business systems. Reuse existing app code ASP.NET, Node.js, and Python services use managed integrations with no workflow engine in the call path. Publish connectors to agents Turn any connector into an MCP server in one step so Copilot and other agents can call it as a tool. Connections: authenticate once, reuse everywhere Connections are where the Logic Apps connector ecosystem pays off. You get the same broad catalog of first-party Azure services and popular SaaS apps — built on years of connector investment — without bringing a workflow engine along for the ride. You create a connection to a service, authenticate it once, and then any number of apps and connectors reuse it. Creating one is deliberately simple, which is the point: In the Connector Namespaces portal (connectors.azure.com), open your namespace and select Connections > Create connection. Find and select the connector — say, Office 365 Outlook. Give the connection a clear, specific name so it's easy to pick later. Sign in to authorize, and complete any extra steps the service requires. Confirm the connection shows as healthy on the Overview page — it's now ready for your apps to use. Supported authentication types today are OAuth, API key, and Basic. And because the namespace stores and rotates the credentials, your app never touches a raw secret. Triggers: deliver events to the compute you already run A trigger is an event subscription your app registers on a connector — new email, updated record, new file. When the source system raises that event, the namespace delivers the payload to your compute. And it does the hard part for you: it manages polling schedules and webhook registration based on what the underlying service supports, so you don't stand up or maintain subscription infrastructure. Your app can receive those events running on: Azure Container Apps Sandboxes Azure Functions Direct HTTP — App Services or self-hosted ASP.NET, Node.js, or Python on AKS or VMs, through the same connector namespace. Two details that matter in practice: a trigger is defined independently of any specific app, and multiple apps can subscribe to the same trigger event over the same connection. Actions, for contrast, run synchronously when your app calls them; trigger delivery uses webhooks or pull-based subscriptions depending on the connector and source service. You can learn more about how to use the Connectors SDK to inject connectors on Azure Functions here. MCP servers: turn connectors into agent tools This is the part I'm most excited about. An MCP server in your namespace exposes tools that AI agents — Copilot, custom agents, any MCP-aware client — can discover and call, using the same connection model as everything else. That's how you put your line-of-business systems directly in front of an agent without writing tool wrappers or standing up hosting. There are two ways to get one. Managed MCP servers Take any connector in your namespace and publish it as an MCP server in a single step. The namespace builds and configures the server — tool definitions, lifecycle, runtime — and the only thing you do is authenticate the underlying connection. If you can create a connection, you can give an agent a tool. Hosted MCP servers Sometimes you want a ready-made server rather than one projected from a connector. Hosted MCP servers are pre-built images from a curated catalog that the namespace runs in dedicated compute it provisions for you. You own the configuration; the platform handles hosting, scaling, networking, lifecycle, dependencies, health monitoring, and credentials. When you deploy one, the namespace pulls the image, provisions the runtime with your config, and exposes a secure MCP endpoint agents can connect to. The curated catalog during preview includes: Playwright — browser automation tools for navigation, screenshots, and page interaction. Azure SQL — SQL operations exposed as MCP tools through Data API builder, with entity abstraction, RBAC, and caching so agents work through a controlled, secure contract. It's a deliberately curated set today, and it expands over time based on demand. You can learn more about Hosted MCP Servers here. How agents authenticate Hosted MCP servers have two auth boundaries: Inbound (client to server) — OAuth with Microsoft Entra ID. Connections from GitHub Copilot in VS Code work out of the box; other MCP clients need a little extra config. Outbound (server to downstream system) — either a managed identity assigned to the namespace, or on-behalf-of (OBO) using the calling user's identity for delegated access. How it fits together End to end, the flow for connectors is short: Create a connector namespace resource in your subscription. Create one or more connections to the services you want — say, an OAuth connection to Microsoft 365. Your app — in Functions, Container Apps, App Service, or self-hosted compute — references the namespace and connection through a Connector SDK, then subscribes to triggers or calls actions. The namespace handles authentication, request signing, polling, webhook subscription, and retries. Your app gets back typed responses and event payloads. For MCP servers, it's the same shape: create the namespace, add a managed or hosted server from the catalog, authenticate the underlying connection, and agents can find the server, read its tool catalog, and invoke tools. Where you can run it Azure compute — App Service, Container Apps, and Functions can all consume connector operations. Self-hosted — any self-hosted service works too: ASP.NET, Node.js, or Python on AKS or Azure VMs. Agents, directly — Copilot extensions and MCP-aware clients call tools on MCP servers in your namespace without going through a separate compute layer; the namespace provides the compute that runs the servers. Security and governance, by default Credentials stay with the namespace — it stores, manages, and rotates them; your app never handles raw secrets. Network isolation — restrict access with virtual network integration and private endpoints. RBAC — control who can create connections, register triggers, and invoke actions. Observability — diagnostic logs and correlation IDs flow to Azure Monitor for end-to-end tracing across the namespace and your compute. Before you build: preview realities I'd rather you go in clear-eyed. While Connector Namespace is in preview, keep these in mind: Consideration What to expect No SLA Not recommended for production workloads during preview. Region availability Limited regions today; the list expands over time. Connector coverage High-usage and standard connectors first; enterprise connectors like SAP, IBM MQ, and Oracle Database follow in later waves. Identity API key and OAuth connections now; managed identity for connections comes later (and arrives earlier for select MCP servers). Versioning SDK and namespace runtime versions are paired during preview — expect breaking changes between milestones. Pricing The pricing model isn't finalized; the metering shape may change before GA. Try it, and tell us your feedback If you've ever shipped an integration and then spent the next quarter maintaining its plumbing, this is for you. The preview is open: create a namespace from the Azure portal, wire up a connection at connectors.azure.com, and call your first action or publish your first MCP server. It is easy to start here: Learn more: What is Azure Connector Namespace? Quickstart: Create and manage connector namespaces Create reusable connections in connector namespaces Hosted MCP servers in Azure Connector Namespace Related Blog Posts: Azure Functions - Connectors SDK Hosted MCP Server announcement Samples repositories: Using connectors SDK with Azure Functions This is a preview, which means your feedback genuinely shapes where it goes — which connectors come next, which MCP servers land in the catalog, where the rough edges are. Bring issues, feature requests and feedback to our GitHub page. I read it. Let's build the integration layer you actually want to use.
MCP Test Console and Git Repository synch in Azure API Center
Why This Matters As organizations race to build AI-powered applications, the Model Context Protocol (MCP) has emerged as the standard way to connect AI agents with external tools and data sources. Managing these MCP servers at enterprise scale, however, has been a growing challenge — until now. AI agents are only as useful as the tools they can access. MCP servers expose those tools — from databases and internal APIs to third-party services — in a standardized way that any AI agent or model can consume. As your MCP ecosystem grows, so does the challenge of keeping track of what's available, what's working, and what your teams are actually using. Azure API Center already serves as a centralized registry for APIs across your organization. Now it extends that same governance model to MCP servers, complete with developer-friendly discovery, live testing, and automated synchronization from your source repositories. New Feature: MCP Test Console in the API Center Portal Developers can now test MCP server tools interactively without leaving the Azure portal. Once an MCP server is registered in your API Center inventory, the API Center portal — your organization's customizable developer portal — surfaces a dedicated test console on the server's Documentation tab. Developers simply select a tool, click Run tool, and immediately see the response. This means your teams can: Validate tools before connecting them to agents — no more building a test harness from scratch. Explore tool schemas interactively — the portal surfaces endpoint details and input/output schemas alongside the live console. Onboard faster — developers browsing your internal MCP registry can go from discovery to verified integration in minutes. The MCP server tiles in the portal provide a clear, browsable view of all registered servers. Each tile surfaces the server's endpoint URL, available tools, and installation instructions for Visual Studio Code — giving developers everything they need to get started in one place. Getting started: Set up your API Center portal, then navigate to any registered MCP server. On the Documentation tab, select a tool and click Run tool to open the test console. New Feature: Synch MCP Servers from a Git Repository Managing API assets shouldn't require manual registration every time something changes. With Git repository integration, Azure API Center can automatically sync assets — including MCP server definitions — directly from your source repository. How It Works When you connect a Git repository to your API Center: An environment is created in your API Center representing the repository as an asset source. API Center regularly synchronizes MCP servers from the repository into your inventory — no manual intervention required. Assets appear in your inventory on the Inventory > Assets page with a visual link indicator, making it easy to identify which assets are source-controlled. This is especially valuable for teams that maintain MCP server definitions, skill files, or OpenAPI specs in version control. As your repository evolves, your API Center inventory stays current automatically. Setting It Up Step 1: Secure your access credentials (for private repos) If your repository is private, store a personal access token (PAT) as a secret in Azure Key Vault. Your API Center instance uses a managed identity to retrieve this secret securely — you can configure the managed identity manually or let API Center handle it automatically during the integration setup. Step 2: Connect the repository In the Azure portal, go to your API Center and navigate to Platforms > Integrations > + New integration > From Git repository. You'll configure: Repository URL — including an optional branch and subfolder path (e.g., https://github.com/<org>/<repo>/tree/main/skills). Git provider — such as GitHub. Asset type configuration — API Center defaults to a skill asset type with the file pattern **/skill.md, but you can add additional asset types to match your repository structure. PAT reference — select the Key Vault secret containing your PAT, if applicable. Environment details — give the repository environment a friendly name, resource ID, type (e.g., Production), and lifecycle stage for synced assets. Step 3: Let the sync run Once created, the integration runs automatically. Your assets will appear in the Inventory > Assets view, linked to their source in the repository. Access Control for Private Repositories The integration uses Azure's managed identity framework to authenticate to Key Vault. Assign your API Center's managed identity the Key Vault Secrets User role on your Key Vault to grant the necessary read access. If you prefer, API Center can configure this automatically — just enable the Automatically configure managed identity and assign permissions option during integration setup. Bringing It Together: A Complete MCP Governance Story Together, these two features complete an end-to-end workflow for enterprise MCP governance: Register → Connect your Git repository and let API Center automatically synch your MCP servers and skills as they evolve. Discover → Developers and AI engineers browse the API Center portal to find the right MCP server for their agent, with full schema visibility and endpoint details. Test → The built-in test console lets developers validate tools interactively before committing to an integration. Govern → Use API Center's access management capabilities to control who can view and consume specific MCP servers across your organization. And if you're building MCP servers on Azure services, the registry integrates directly with Azure API Management, Azure Logic Apps, and Azure Functions — so your MCP ecosystem and your API ecosystem share a single source of truth. Get Started Register and discover MCP servers in Azure API Center Synchronize API assets from a Git repository Set up the API Center portal Explore MCP Center — Azure API Center's public MCP registrySimpler, scalable file share management in Azure - now generally available
Linux workloads in Azure are scaling faster than ever, powering everything from container platforms, analytics pipelines, SAP environments to line-of-business applications. As these workloads grow, infrastructure teams commonly run into challenges with scale, cost management, complexity and compliance. IT organizations need more granular control over management and isolation boundaries for file shares independent of storage accounts, to prevent multiple application teams sharing the same capacity pools, limits, and configuration surface across different storage services. Infrastructure administrators seek operational simplicity with managing access control, policy and networking isolation for file shares, so application teams can focus on business logic and development agility. We are announcing the general availability of a new service management experience for premium SSD file shares (NFS) which allows each file share to be created, secured, scaled, and billed independently, without being tied to a storage account. Key benefits include: Familiar and intuitive file share management: Aligns user experience with on-premises NAS and file server paradigms, improving usability compared to the classic model. Infrastructure-as-Code: Define naming, capacity, IOPS, networking, tags, and security in Bicep or ARM templates for simplified automation with your favorite DevOps tools. Scale to match the workload: Support for up to 10,000 file shares per subscription per region, with 2.5x faster file share provisioning experience. Share-level security and networking: Network restrictions, snapshots, and encryption scoped to the individual share, making isolation boundaries match workload boundaries. Per-share cost visibility: Billing meters emit under the file share resource, teams can crossbill accurately, track per-workload costs, and improve chargeback without workarounds. Independent performance, security, and billing per share Combined with the provisioned v2 model, each file share is independently provisioned with its own storage, IOPS, and throughput. This allows organizations to align file shares directly to application or tenant boundaries, rather than grouping them under shared infrastructure constructs. For multi-tenant SaaS platforms, this enables a natural one-to-one mapping between tenants and file shares. Each tenant operates within its own performance envelope, allowing steady workloads and bursty workloads to scale independently without contention. This reduces the need for capacity planning tradeoffs or overprovisioning to accommodate peak usage across tenants. This isolation extends beyond performance; each file share carries its own encryption in transit settings, RBAC, policy, and network boundaries. For example, production tenants can be isolated with dedicated private endpoints, while development environments can operate under more flexible configurations. These boundaries align directly with application design, making systems easier to reason about and manage at scale. Finally, treating each file share as its own resource simplifies cost management. Teams can tag and track usage at the workload or tenant level, enabling more accurate chargeback and better visibility into resource consumption. This makes it easier to understand how individual workloads contribute to overall spending without introducing additional tracking mechanisms. Start easy, scale big Cloud-native Linux applications often scale dynamically, so the underlying storage platform must provide resources quickly and support higher scale limits to keep pace with workload demand and enable teams to quickly provision infrastructure and keep pace of development. The new file share experience supports up to 10,000 file shares per subscription per region, making it practical to use a dedicated share for each application, environment, or tenant without running into platform limits. It also provides faster provisioning, with time to first share 2.5x times faster than classic file shares, so teams can spend less time waiting on infrastructure and more time building, testing, and shipping. “Provisioning is fast and integrates seamlessly with Linux environments through NFS.” - Siam Commercial Bank Data protection with snapshots Linux workloads using shared file storage require robust data protection. With the new service management experience, customers can continue to leverage point-in-time incremental snapshots with up to 200 snapshots per share. You can also now edit metadata on individual snapshots, making it easier to organize and identify recovery points. Whether you need short term restore points or need to retain data for compliance requirements, snapshots provide an easy and cost-effective recovery mechanism. Get started today The new file share experience is available for NFS 4.1 file shares on SSD storage, using the provisioned v2 billing model with LRS and ZRS options. Whether the deployment model is ARM templates, Bicep, MCP server, or custom CI/CD pipelines, file shares are scriptable, repeatable, and automatable through the same tooling used for the rest of Azure infrastructure. Explore our documentation for step-by-step guidance. We're continuously enhancing the new file share experience with the goal of achieving full feature parity while delivering improved scale and performance limits. We would love to hear your feedback, please fill out the survey to share your thoughts. Learn more Planning for an Azure Files deployment How to create a file share Scalability & performance targets For questions or feedback, contact us at azurefiles@microsoft.com.Built-in gateway support for workspaces in Azure API Management
Workspaces in Azure API Management let platform teams hand off API ownership to individual API teams while keeping centralized governance. Until now, using them meant deploying a dedicated workspace gateway on the Premium tier — adding cost, operational overhead, and limiting regional availability. That requirement is going away. Workspaces can now be associated directly with the built-in gateway, and this capability is generally available. What changes Available in more tiers. Use workspaces on the built-in gateway in any API Management tier except Consumption. Available in every region. Create workspaces in any region where API Management is supported. All built-in gateway capabilities apply. Workspaces deployed with the built-in gateway inherit features that dedicated workspace gateways don't offer today, including multi-region deployments, custom hostnames, and Private Link connectivity. Availability Rolling out now to v2 tiers, with Azure portal UI support expected around July. Rollout to classic tiers (Developer, Basic, Standard, Premium) will begin by August and may take up to a few months to complete. Get started Learn more about workspaces and how to deploy them on the built-in gateway.GA: Azure API Center Now Supports Plugin Registration
As organizations scale their AI and integration ecosystems, one challenge keeps surfacing: developers don't have a reliable, governed way to discover and reuse the plugins their teams have already built. Plugins end up siloed in individual repos, shared over Slack, or duplicated across teams — slowing down development and creating governance blind spots. What's new With this update, developers can register plugins directly into Azure API Center's enterprise catalog. Once registered, plugins are discoverable, governable, and consumable alongside the rest of an organization's API and AI portfolio — no more hunting across repositories or relying on word-of-mouth to find what's already been built. Why it matters Plugins are increasingly central to how AI-powered applications are built. Agents depend on them. Integrations are built on top of them. But without a governed home, even well-built plugins go undiscovered and get rebuilt from scratch. Plugin registration in Azure API Center helps organizations: Centralize plugin discovery within a governed catalog, so developers always know where to look Surface vetted plugins that teams can confidently find and reuse — reducing duplication and accelerating development Align plugins with source-controlled workflows, keeping development practices consistent across the catalog Reduce friction between building a plugin and enabling it for real-world integration One catalog for your entire AI ecosystem This update reflects a broader vision for Azure API Center: a single, unified catalog for everything an organization builds and consumes — APIs, plugins, agents, and AI assets. By bringing plugins into this experience, teams can operationalize reusable integration and AI capabilities at scale, with the governance and discoverability that enterprise development requires. Whether your teams are building copilot extensions, orchestration layers, or custom integrations, Azure API Center gives them a governed foundation to build on — and a shared place to discover what's already there. Learn more about Azure API Center and how organizations are building centralized catalogs for APIs, plugins, agents, and AI assets.
