Azure OpenAI Decisions API: Practical Classification

Use Azure OpenAI Decisions API outputs for bounded classification. Includes a safe routing example plus current availability, privacy, and pricing caveats.

Harllens George de la Cruz | Published: 2026-11-11 | Updated: 2026-11-11

Azure OpenAI Decisions API editorial cover showing a typed /openai/v1/decisions response branching into Predicate, Choice, and Score outputs.
Azure OpenAI Decisions API cover: typed decision outputs for bounded classification, using an unchanged official Azure OpenAI icon. Original deterministic editorial composition with the unchanged official Azure OpenAI icon from Microsoft Azure Architecture icons; not a product screenshot or endorsement.

The Azure OpenAI Decisions API is a dedicated endpoint for asking a model to evaluate evidence and return typed answers, rather than a paragraph of generated text. It can check a predicate, select from options you define, or score an input against an ordered rubric. This guide shows how to use those outputs as bounded application signals, with a synthetic support-triage example and the current availability, privacy, and pricing caveats.

What the Decisions API does

The endpoint is /openai/v1/decisions. A request supplies a model deployment, shared input, and one or more named questions. The response contains an answers array and token usage. The documented question types are:

Type Output Good fit
predicate A probability from 0 to 1 that a condition is true Is a customer asking for a refund? Does this image show visible damage?
choice One value from your fixed options, with probabilities and confidence Which support queue should receive this request?
score A probability-weighted average over ordered level indices, plus level probabilities and confidence How urgent is this issue on a defined scale?

Use choice for a category and score for an ordered scale. A score can fall between the levels: if the model assigns probability across adjacent levels, the returned number is their weighted average, not necessarily one of the labels. Microsoft documents the request structure, response types, and these distinctions in Use the Azure OpenAI Decisions API.

The API is different from an endpoint intended to write a free-form explanation or produce an object that follows an arbitrary JSON schema. Microsoft's guidance points to structured outputs with the Responses API for schema-constrained objects, and function calling when a model should request a tool call with arguments. Choose the endpoint based on what your application needs to consume.

Availability and prerequisites

Microsoft's Foundry announcement describes GPT-6 Luna as generally available in Microsoft Foundry, but that does not mean this endpoint is available in every model region. The current Decisions API page says gpt-6-luna is the only supported model, describes a rollout to regions where it is available, and explicitly excludes East US 2. It lists an Azure subscription, an Azure OpenAI resource, and a gpt-6-luna deployment as prerequisites, and documents both API-key and Microsoft Entra ID authentication. Verify the endpoint and deployment options for your resource before making it a hard dependency; treat the endpoint documentation as the authority for this API.

The model parameter is the deployment name, not necessarily the underlying model's canonical name. In Microsoft's examples the deployment is named gpt-6-luna; if yours has a different name, send that deployment name. For the documented JavaScript examples, Microsoft lists Node.js and openai version 7.30.0 or later.

A practical integration pattern

Treat the API response as an input to deterministic application policy, not as the policy itself. Name each question uniquely, define narrow instructions and distinct options, include a fallback choice such as other, and decide in application code what happens on a low-confidence result or refusal.

Conceptual flow from application evidence through named Decisions API questions to typed outputs, validation, and a controlled application route.

Synthetic worked example: support queue triage

The sample below classifies a synthetic ticket. It asks for an issue category and a refund-request signal. The identifiers, options, thresholds, and example output are illustrative; they are not a real customer record or a measured model result.

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: process.env.AZURE_OPENAI_BASE_URL,
  apiKey: process.env.AZURE_OPENAI_API_KEY,
});

const decision = await client.decisions.create({
  // Set this to the name of your gpt-6-luna deployment.
  model: process.env.AZURE_OPENAI_DEPLOYMENT,
  input: "Synthetic ticket: The glass jar arrived cracked. Please replace it.",
  questions: [
    {
      type: "choice",
      name: "issue_type",
      instructions: "Choose the main support category supported by the message.",
      choices: [
        { value: "item_damage", description: "The delivered item is broken or damaged." },
        { value: "delivery", description: "The request is about shipping or arrival." },
        { value: "billing", description: "The request is about a charge or payment." },
        { value: "other", description: "The message does not fit another option." },
      ],
    },
    {
      type: "predicate",
      name: "replacement_requested",
      instructions: "Does the customer explicitly ask for a replacement?",
    },
  ],
});

const issue = decision.answers.find((answer) => answer.name === "issue_type");
const replacement = decision.answers.find((answer) => answer.name === "replacement_requested");

// Example policy only: ambiguous results go to a person; the model never issues a replacement.
const queue = issue?.type === "choice"
  && issue.choice !== "other"
  && issue.confidence >= 0.75
  ? issue.choice
  : "human_review";

const replacementSignal = replacement?.type === "predicate"
  ? replacement.probability
  : null;

console.log({ queue, replacementSignal, usage: decision.usage });

For this synthetic ticket, an illustrative response might be issue_type = item_damage with a confidence above the sample threshold and replacement_requested = true with a high predicate probability. That output can suggest the damage queue and help a person prioritize review. It does not prove that the jar was damaged, establish eligibility, or authorize a replacement. Your application should validate the order and policy using its trusted systems, handle missing or refused answers, and require the appropriate confirmation and human approval before a consequential action.

The threshold 0.75 is a placeholder, not a Microsoft recommendation. Calibrate thresholds against representative, reviewed examples and measure both false positives and false negatives. Also test an out-of-scope message, mixed intents, absent evidence, an unrecognized answer type, a refusal, and an API failure. Route uncertainty to a safe fallback rather than silently selecting the first option.

For the code sample, set AZURE_OPENAI_BASE_URL to https://<resource-name>.openai.azure.com/openai/v1/, AZURE_OPENAI_DEPLOYMENT to the name of your gpt-6-luna deployment, and AZURE_OPENAI_API_KEY in server-side secret storage. Do not expose an Azure OpenAI key in browser code. Entra ID authentication is also supported if it better fits your application's identity and secret-management design.

Input, images, and response handling

Text can be sent as a string or as user messages. A message can also combine input_text and input_image parts. The current Learn page lists PNG, JPG, WebP, and GIF support, up to 128 images per request, with a maximum combined image size of 32 MB. Keep image handling in scope only when visual evidence is genuinely needed, and test it with examples that reflect the lighting, angles, and image quality in your real workflow.

Read answers by name and check each answer's type before accessing fields such as choice, confidence, or probability. The API can return a refusal; treat that as a distinct outcome. Log the request identifier and token usage needed for operations, but avoid retaining raw input or sensitive output longer than your policy allows.

Privacy, data handling, and pricing

Microsoft's Foundry Models data, privacy, and security guidance says prompts and completions for models sold by Azure aren't available to other customers and aren't used by model providers to improve models or services without permission or instruction. The same guidance describes service processing for operation, abuse monitoring, and content safety. Processing geography depends on deployment type: Standard is within the specified geography, while Global and Data Zone deployments can process across the applicable geography or zone. Stateful features can also retain data according to their configuration. Apply your own data classification, retention, access, and regional requirements to the selected resource and deployment; this isn't a blanket guarantee that no processing or monitoring occurs.

Decisions responses include token usage, but token counts aren't a price quote. The Decisions API page points to the Azure OpenAI pricing page rather than publishing an endpoint-specific rate. Microsoft's September 22 Foundry pricing announcement lists GPT-6 Luna Standard short-context rates of USD $0.10 input and $0.50 output per million tokens for Global, and $0.12 input and $0.60 output for EU Data Zone. Long-context, cached-token, other deployment, regional, and contractual rates differ. These are model rates, not an endpoint-specific quote or full task-cost estimate. Check the live pricing page, selected deployment, region, and agreement before budgeting.

Common mistakes to avoid

  • Treating a predicate probability or choice confidence as a calibrated guarantee.
  • Using score when the application needs one fixed category, or interpreting a fractional score as a selected level.
  • Omitting a fallback option for inputs outside the category list.
  • Using the model result as the authorization decision for refunds, eligibility, account changes, or other consequential actions.
  • Sending a model name where the API expects your deployment name.
  • Assuming the endpoint is available in every Azure OpenAI region or that a model listed elsewhere is supported by this endpoint.
  • Assuming the model's data-handling description removes your own retention, access-control, and compliance responsibilities.
  • Treating published token rates as a quote for a particular request, deployment, or complete workflow.

Next steps

Check region availability and deploy the supported model before writing application code. Start with synthetic inputs and one question type, capture the typed response and usage, and build deterministic handling for low confidence, refusal, unknown answers, and service errors. Expand only after a reviewed evaluation set shows that your thresholds and fallback route are appropriate.

Conclusion

The Azure OpenAI Decisions API is useful when an application needs a predicate, a choice from known values, or a score against ordered levels rather than generated prose. Its typed outputs can make routing and prioritization easier to integrate, but they remain model estimates. Verify the rolling region availability, protect the full data flow, validate outputs in deterministic code, and keep consequential decisions behind your application's policy and human review.

Sources

Related reading

Editorial note: This AI-assisted guide uses synthetic examples. No Azure resource, endpoint call, or customer data was accessed or tested.