OpenAI's Decisions API Is Out of Beta: Should You Route Leads With It?

Should you route leads with OpenAI's new Decisions API?

Maybe, but not on day one. OpenAI's changelog says the Decisions API became generally available on October 22, 2026, after a beta that started on October 6. It returns typed answers instead of free text, which suits lead routing well. I would test it beside your current rules before letting it own a live pipeline.

I build lead routing systems for B2B teams, so a release like this lands on my desk fast. Clients ask whether they should swap their HubSpot workflow, their Zapier filter, or their Make router for a model call. The honest answer is that this API removes one real pain point, but it does not remove the need for rules, tests, and a human fallback.

This piece covers what OpenAI actually shipped, what it changes for go-to-market teams, and how I would run a fair test before anyone trusts it with real leads.

What is the OpenAI Decisions API?

The Decisions API is an OpenAI endpoint built for one narrow job: answering fixed questions about an input. You send text, images, or JSON plus a list of questions, and it sends back an answers array. Each answer is a probability, a choice from a list you supply, or a score on a scale you define.

According to OpenAI's developer guide, requests go to a dedicated endpoint, POST /v1/decisions, and gpt-6-luna is the only model it currently supports. You give each question a unique name, and the API echoes that name back next to its answer. That small detail matters more than it sounds, because it means your automation can read answers by name instead of parsing a paragraph.

The guide describes three answer types. A predicate returns a probability from 0 to 1 that a condition is true. A choice returns one of the values you supplied. A score returns a probability weighted average across ordered levels, and the guide says a score question takes 2 to 10 levels. OpenAI's own framing is that you use these answers to classify content, route requests, and prioritize work.

What did OpenAI change when it left beta?

OpenAI's changelog lists three dated entries. The API launched in beta with gpt-6-luna on October 6, 2026. Native Decisions support arrived in GPT-Live on October 15. On October 22, the changelog says the API became generally available. The guide now says one request can carry between 1 and 400 questions.

For a routing system, general availability is mostly a signal about stability. I do not wire a beta endpoint into anything that decides who calls a buyer. A generally available product does not mean nothing will change, but it does mean the vendor is ready for production traffic and is less likely to rename fields under you.

The 400 question ceiling also matters. A single inbound lead rarely needs more than five or six questions. But if you want to score a backlog of accounts against a rubric, or ask many small yes or no questions about one company, you can batch them into one call instead of chaining dozens of prompts together.

Why does a typed answer matter for lead routing?

A typed answer matters because routing logic needs a value it can compare, not a sentence it has to interpret. When a model returns prose, your automation needs a second step to parse it, and that parsing step is where most AI routing breaks. A choice or a probability drops straight into a filter or a branch.

Here is a pattern that shows up again and again. Someone adds an AI step to a Zap that says "classify this lead as enterprise, mid-market, or small business." Most of the time the model replies with one word. Sometimes it replies with a polite sentence, or adds a reason, or invents a fourth category. The filter downstream does not match, and the lead lands nowhere. Nobody notices until a sales rep asks where the leads went.

The choice answer type closes that gap by design, because the answer must be one of your supplied values. OpenAI's guide also recommends adding a fallback choice such as "other" for inputs your categories do not cover. I would make that fallback mandatory and send every "other" to a person. I have written before about how to route low-confidence AI classifications to a human, and the same rule applies here.

How much does the Decisions API cost to run on inbound leads?

OpenAI's guide prices gpt-6-luna on the Decisions API at $0.10 per million uncached input tokens, and output tokens are not charged. For a typical inbound form, the cost per lead is tiny. The bigger cost is the engineering time to test it properly and the price of a wrong route.

The guide also notes that regional processing premiums and long context pricing multipliers apply, so check OpenAI's pricing page for your setup before you build a budget. A form submission with a company name, a job title, a free text message, and a few enrichment fields from Clay or Apollo is a short input. Even at high volume, the model bill is unlikely to be the line item that worries a finance team.

What I would actually budget for is the cost of being wrong. A misrouted enterprise lead that waits two days in a small business queue can cost more than a year of API calls. That is why I put the money and time into the test harness, the logging, and the human review queue, not into squeezing the per call price.

Where would the Decisions API fit in a GTM stack?

It fits as one step between capture and assignment. A lead comes in from a Webflow form or a demo request, gets enriched, then the Decisions API answers a few fixed questions about it. Your existing rules in HubSpot, Salesforce, or n8n then use those answers to pick an owner and a next action.

I would not let the model pick the owner directly. Ownership depends on territory, capacity, account history, and existing deals, which live in your CRM and change daily. Those are rules, and rules are cheaper, faster, and easier to audit than a model call. The model's job is to read the messy parts a rule cannot, like a free text message that says "we are evaluating three vendors and need this before our board meeting."

So the questions I would ask it are narrow. Is this message a sales inquiry, a support request, a partnership pitch, or a job application? What is the probability this person has buying authority, based on title and message? How urgent does the request sound, on a three level scale? Each answer feeds a branch that already exists. If you are still deciding the routing rules themselves, start with who should get a lead the moment it arrives before you add any model.

What are the risks of letting a model make routing calls?

The main risks are silent drift, false confidence, and accountability gaps. A model can start answering differently after an update, a probability can look precise while being poorly calibrated for your leads, and a sales team will stop trusting routing the first time a big deal lands in the wrong queue without an explanation.

Calibration is the one people skip. A probability of 0.8 from the API is the model's estimate, not a measured rate for your pipeline. OpenAI's guide says to set thresholds using labeled examples from your own application and to weigh the cost of false positives against false negatives. That is exactly right, and it means you need a labeled set of past leads before you pick any cutoff.

Data handling is the other question your security reviewer will ask. The guide says the API supports Zero Data Retention and HIPAA use for eligible customers, and that data residency is available in supported regions. Eligibility is the key word. Confirm what your account actually qualifies for before you send personal data from form fills through it.

How would I test the Decisions API before trusting it?

I would run it in shadow mode for two to four weeks. Every new lead goes through your current routing as normal, and the Decisions API answers the same questions in parallel without changing anything. You log both results side by side, then compare them against what sales actually did with each lead.

Before shadow mode, I would build a labeled set from past leads. Pull a few hundred closed records from the CRM, including won, lost, and disqualified, and mark the right answer for each question you plan to ask. Run the API over that set and see where it disagrees with the labels. That gives you a first threshold and a list of the lead types it struggles with.

During shadow mode, I watch three numbers: how often the model agrees with the current rules, how often it disagrees and turns out right, and how often it lands on the fallback choice. If the fallback rate is high, your categories are wrong, not the model. If disagreements where the model was right cluster in one segment, that segment is where to switch it on first. I would also run the same checks I use to test an AI classification step before it routes leads, because this API is still a classifier underneath.

What should you do next?

Do not rebuild your routing this week. Pick one question your current rules handle badly, usually reading free text intent, and test the Decisions API on that question alone. Label past leads, run shadow mode, log every answer, and only switch it on for the segment where it clearly beats the rule.

My view is that this release is good news for GTM engineering, because it makes the boring, reliable version of AI routing easier to build. Typed answers, a fallback choice, and named questions are the things I used to bolt on by hand. The discipline around them still matters more than the model.

If you want help deciding where a model belongs in your lead flow, or you want a shadow test set up before anything goes live, reach out. Let's chat about your routing and what it should do with the next lead that comes in.