Once a UK SME has committed to a bespoke build — the moment after the “Copilot or custom” question is settled — the next decision lands on the table almost immediately: which API do we build on? In 2026 there are three serious contenders for UK businesses, and the right choice is rarely the one with the loudest model. This is a working buyer’s guide to the Claude API for business, Azure OpenAI, and the OpenAI API direct — written for the operator who has to sign the procurement and live with the decision for the next five years.
The short version: all three options run frontier-class models, so the decision is not really about raw capability for typical UK SME workloads. It is about control plane, residency, identity, and how the workflow integrates with the rest of your stack. The framework below is the one we use inside our own discoveries when scoping AI integration services, and it is the same framework that shaped the recent property management case study.
For most UK SMEs commissioning their first or second bespoke AI build, the field of viable APIs has narrowed to three: the Claude API direct from Anthropic, Azure OpenAI Service inside an existing Microsoft tenant, and the OpenAI API direct from OpenAI. There are other options — AWS Bedrock, Vertex AI, on-prem open-weight models — but for businesses without a deep ML engineering team or an existing AWS or GCP footprint, the three above account for the overwhelming majority of viable production builds we see in the UK SME segment.
By 2026 the gap between frontier-class models on typical UK SME workloads — classification, extraction, summarisation, routing, drafting — is narrow enough that any of the three will deliver acceptable quality if the prompt and evaluation harness are competent. What separates them is the control plane around the model: where data sits, which identity provider it inherits, what governance posture is already in place, and how the API surface integrates with your existing systems. That is the real comparison.
The Claude API is the right call when the workflow needs strong long-context reasoning, multi-step tool use, or sits partly outside the Microsoft 365 tenant. Three patterns in particular play to its strengths. The first is complex document or workflow reasoning — long-context windows and consistent instruction-following make it well-suited to reading a contract, a tenancy file, or a multi-attachment email thread and producing a structured response another system can consume. The recent property management case study uses exactly this shape.
The second is builds that touch systems outside Microsoft 365 — a customer-facing portal, a partner integration, a public-facing chatbot, a workflow tool that lives in its own application surface. Here the “inside the tenant” advantage of Azure OpenAI does not apply, and a clean API surface with documented residency and zero data retention options is the more useful starting point. The third is multi-step agentic workflows — tool use, structured outputs, and the ability to chain reasoning steps reliably. For builds that genuinely need an agent to plan, call tools, and verify its own output, the Claude API has been our default through 2026.
Azure OpenAI is the right call when the workflow lives inside the Microsoft 365 tenant and the governance and identity integration is more valuable than any other consideration. For a large share of UK SMEs — particularly those already standardised on M365 with Entra ID, Defender, and Purview — that is the situation, and Azure OpenAI is the cleanest default.
The advantage is everything around the model. Authentication inherits Entra ID. Logging, monitoring, and threat detection inherit Defender for Cloud, so the workload sits inside the same security posture as the rest of the environment. Data protection and sensitivity labelling inherit Purview. The EU Data Boundary and UK regional options keep processing where regulated SMEs need it. Procurement runs through the existing Microsoft enterprise agreement rather than a new vendor onboarding. For workloads that genuinely belong inside the tenant — an internal copilot bolted onto SharePoint and Dynamics, an extension to a Power Platform build — choosing anything other than Azure OpenAI is usually adding friction without buying anything in return.
OpenAI API direct is the right call in a narrower set of cases: rapid prototyping, exploratory builds, internal tooling where the eventual users are already familiar with ChatGPT and consistency matters, or workloads that depend on the wider OpenAI ecosystem (voice models, image models, the broader plugin and assistant infrastructure) that Azure’s release cadence has historically lagged.
The trade is data residency. By default, OpenAI API direct processes data in the US, and although enterprise plans have introduced more residency flexibility, this still requires a deliberate procurement conversation and contract review for any regulated UK SME workload. For internal tooling that does not touch personal data, exploratory work, or builds where you are accepting US processing in exchange for ecosystem breadth, this is fine. For production workloads in finance, legal, healthcare, property, or anything subject to ICO scrutiny, it is usually the wrong default.
This is where the comparison genuinely changes character for UK businesses. Azure OpenAI supports the Microsoft EU Data Boundary and UK regions; for tenants configured correctly, processing and storage stay within the EU or UK and the controls are inherited from existing Microsoft tooling. The Claude API offers documented residency commitments covering UK and EU processing on enterprise plans, and zero data retention configurations are available where the contract requires them. The OpenAI API direct is US-hosted by default, with residency options requiring an enterprise contract and active configuration.
The wider governance lens matters too — the "is this build defensible to an auditor" question we covered in AI governance for SMEs. Azure OpenAI inherits the strongest answer to that question because it is plugged into Purview and Defender by default. The Claude API answers the question well but requires a deliberate documentation step — logging, audit trails, and DPIA work that you do in your own code rather than inherit from the platform. The OpenAI API direct answers the question least well by default and usually needs the most parallel tooling to bring it up to the standard regulated SMEs expect.
For typical UK SME workloads — single workflows processing hundreds of items per day — the inference cost on any of the three APIs is a rounding error against the engineering. The property management case study runs at around £180 per month for the model API on roughly 220 emails per day. A document processor build of similar shape costs in the same order of magnitude. The headline cost of a custom AI tool is the engineering, the evaluation harness, and the operate-phase retainer — not the tokens.
Two cost considerations matter beyond the per-token rate. Azure OpenAI’s Provisioned Throughput Units let you fix capacity and cost for predictable workloads, which becomes economically interesting once a workflow ships and volume stabilises; Anthropic offers similar commitment-based pricing for enterprise customers. The second is the cost of changing APIs later — rarely a model swap, more often a contract re-paper, a fresh data protection impact assessment, and a governance review. That cost is often larger than a year of inference, and it is the reason the API choice is best treated as a five-to-seven-year governance decision rather than a six-month engineering one.
If you take one thing from this post, take this framework. The right API is decided by where the workflow lives and what control plane it needs to inherit.
A meaningful share of the conversations we have end with the recommendation not to commission an API build at all. If the workflow is fundamentally a drafting or summarising task inside Outlook, Word, or Teams, Copilot is genuinely the right tool. If the workflow is a personal-productivity research and writing task, Claude or ChatGPT consumer subscriptions handle it. If the workflow is small enough that a no-code automation in Power Automate or n8n carries it, do that instead.
The decision tree we covered in Copilot vs custom AI tools applies first. Only when a workflow has earned a bespoke build does the API question even arise — and only then does this post matter. Commissioning an API build for a workflow Copilot already handles is one of the failure patterns documented in why AI automation stalls in most UK businesses, and it is an expensive one. If you have a workflow that has earned a bespoke build, the API choice is meaningful and worth half an hour of focused conversation. Our how we work page sets out the discovery, build, and operate phases we use to make that decision in the open with the client.
Book a 30-minute discovery call. We will walk through the workflow, the tenant, and the governance posture, and tell you straight which API is the right call — Claude, Azure OpenAI, or none of them. No sales theatre.
Book a Discovery Call