Azure OpenAI's Decisions API is generally available, returning scores instead of generated text

A scoring endpoint instead of a chat model

Microsoft has made the Decisions API for Azure OpenAI generally available inside Microsoft Foundry, according to a walkthrough by Taswar Bhatti on dev.to, which cites a Foundry announcement dated October 22, 2026. Instead of generating text, the endpoint evaluates an input such as text or an image and returns a typed answer: a probability, a selection from a caller-defined list, or a score positioned along a rubric.

The problem it targets is familiar to anyone building agents. Small judgments, such as which team owns a ticket, whether a customer wants a refund, or how severe an issue is, are typically routed through a chat model. That means prompting for JSON, handling responses that only resemble valid JSON, and treating a stated confidence as meaningful when the model gives no such guarantee. Bhatti argues the Decisions API replaces that pattern with structured answers the caller can rely on.

Three question types, one shared input

According to the Foundry announcement as summarized in the post, the API supports three outcomes, one per question type:

• Probability, called predicate, for whether a condition holds, returned as a value between 0 and 1
• Choice, which picks one value from a list the caller defines
• Score, which places the input on an ordered rubric

A request carries one shared input plus an array of questions, each with a unique name so answers can be matched back to their questions. The response returns an answers array in the same order, along with token usage. Each request supports up to 400 questions, and every question in a request sees the same input.

The endpoint sits under the standard Azure OpenAI resource domain on a decisions path. The model field takes the deployment name; the documentation uses gpt-6-luna, which Bhatti notes is currently the only supported model. Authentication works with either an API key sent in a header or a Microsoft Entra ID bearer token.

Two behaviors from the docs are worth flagging, per the post. A refusal comes back as its own answer type rather than as a low probability, so it needs separate handling in application code. And because all questions share one input, a single request can classify the same content along several axes at once.

How it relates to Microsoft-Decision-1

The post contrasts the new API with Microsoft-Decision-1, an earlier Microsoft provider route that also returned scored judgments rather than prose. The two differ in endpoint and in question-type names, with the post listing noul, choice and score for Decision-1 against predicate, choice and score for the Azure API. Authentication also differs: Decision-1 used Entra ID only, while the Decisions API accepts an API key as well. Documentation coverage varies too, since the Decision-1 quickstart shipped without SDK examples while the Decisions API docs include Python, JavaScript and REST. Both return typed answers.

Calling it from C#

The official documentation does not show a C# SDK for the endpoint, so the walkthrough calls it with HttpClient. The sample project, published on GitHub as OpenAI-DecisionApi-CSharp-Sample, targets .NET 10 and pulls in Azure.Identity plus configuration packages so the endpoint and credentials stay in user secrets or environment variables rather than in source code.

If an API key is configured, the app sends it; otherwise it falls back to DefaultAzureCredential, so a normal az login is enough. The sample mirrors the official Python example: a support ticket about a duplicate charge is evaluated with three questions, covering whether a refund was requested, which of four departments should handle it, and a severity level drawn from three rubric options. Running the same questions means the output can be compared directly against the documented results.

Why it matters

Agents make many small classification decisions per workflow, and pushing those through chat completions spends tokens on prose, invites parsing failures and produces confidence numbers that were never calibrated. A dedicated endpoint returning probabilities, choices and rubric scores moves that work onto a typed contract that is easier to test and less brittle in production. For .NET teams already running Azure OpenAI, general availability means the capability now sits behind the resource, auth and deployment tooling they already have, though as the walkthrough shows they currently need to hand-roll the HTTP call because no C# SDK sample exists. The 400-question batch limit and the decision to make refusal a distinct answer type suggest Microsoft is treating structured judgment as a first-class API surface rather than a prompt-engineering workaround.