Most teams that bolt a language model onto a product eventually hit the same wall. The prompt says “respond only in JSON,” the model complies 94% of the time, and the remaining 6% arrives as a markdown code fence, a polite apology, or a field called isFraud that really needed to be fraud_score. Somewhere between the retry loop and the regex cleanup, you have built a parser where you wanted a decision.
A decision API takes a different position: the output schema is not a suggestion, it is the contract. You send state and a typed question, and you get back a typed answer with a calibrated confidence attached — in a single pass, in milliseconds, deterministically. That shift changes how developers, product teams, and ops engineers build systems that replace brittle hand-written rules or slow, inconsistent chat-model calls.
What a Decision API Is — and What It Is Not
A decision API is an HTTPS endpoint whose job is to return a structured decision, not prose. The difference is architectural rather than cosmetic. With a chat completion endpoint, the model’s native output is a token stream, and JSON is a formatting instruction layered on top — enforced after the fact by a parser, a retry, or a function-calling shim. With a decision engine, the answer types are the interface. A question is declared in code with an expected answer type: a choice drawn from labels you supply, a score on an ordered scale, a truth expressed as a calibrated probability between 0.00 and 1.00, a number on a defined grid, or a spatial point or box locating something inside an image.
That constraint does two useful things. First, it eliminates the failure mode where a downstream service receives a string in a field that was supposed to hold a float. Validation becomes a schema check rather than a cleanup pass, and a rejected answer is a genuine contract violation instead of the normal cost of doing business. Second, it makes answers comparable across time. A probability of 0.87 on a spam question means the same thing today as it did last quarter, which is exactly what allows thresholds to survive model swaps and prompt edits.
Equally important is what a decision API is not. It is not a chatbot behind a POST route, and it is not a thin wrapper that politely asks a generative model to be brief. There is no multi-turn negotiation about answer format and no sampling temperature to argue with. DecisionNode, the decision engine behind its own decision api, frames the model as “System One”: a fast, single-pass judgment rather than a deliberative text-generation loop. The service is deterministic — identical requests produce identical answers — which matters when you are debugging a production incident at 2 a.m. and need to know whether the model changed its mind or your input did.
Inside a Decision Request: State In, Typed Answers Out
The interaction model is deliberately small. A client posts to a single endpoint, POST /v1/decide, with two things: the current state and the questions. State can be plain text, a JSON object, or a set of up to 16 images or video frames. Questions are defined in code, so the caller decides in advance which shape of answer it can consume. A single request can carry several questions at once, which means an order-triage call can ask for a routing label, a risk score, and a probability that the customer is abusive — one round trip, one pass, no chaining.
Every answer arrives with a calibrated confidence, and this is the detail that changes how systems get built. Instead of treating the model as an oracle, code can act instantly above a threshold and route to a re-check, a human queue, or a safe default below it. A support classifier that is 0.96 confident about a billing ticket and 0.55 confident about an ambiguous refund request can behave differently in each case without a separate confidence model bolted on afterward.
Latency and cost are where the design becomes operationally interesting. DecisionNode exposes two models: DecisionNode Flash at roughly 5 ms server-side and 19 ms end to end, priced at $0.035 per 1M input tokens, and DecisionNode MoE at about 9 ms and $0.042 per 1M input tokens. Output tokens are always free, batch discounts are available, and a free daily tier covers development and load testing. For workloads above roughly 10 decisions per second — drones, robots, simulators, continuous machine monitoring — sessions over WebSocket replace per-request HTTPS overhead.
The platform also ships boosters for specialized perception tasks: human age estimation, AI-generated image detection, face detection and recognition, OCR, and depth and segmentation. These matter when an input needs more than a label. A quality-control check that must find a defect rather than merely confirm one can ask for a bounding box instead of a yes/no. SDKs cover TypeScript, Python, Go, Ruby, and curl, alongside MCP tools, webhooks, and AI agent integrations for teams whose callers are autonomous rather than human-driven.
Decision APIs in Production: Routing, Risk, and Machines That Act
The clearest way to understand the pattern is to look at where it replaces something worse. Consider ticket routing and triage. The classic implementation is a nest of keyword rules and regexes maintained by whoever still remembers why urgent outranks urgent!. A decision API replaces that with a declared choice question over your real queue labels, plus a confidence value the router can threshold on. Low-confidence tickets skip the auto-assignment step entirely rather than landing in the wrong team’s backlog. The rules stay in code review, the labels stay versioned, and the same input keeps producing the same route.
Risk workflows follow the same shape with different answer types. A fraud or promo-abuse check typically wants a calibrated probability — the truth type — so an order can be approved, held, or stepped up to verification against a threshold the business owns. Because state can include images, an abuse review can submit uploaded evidence frames and pair the decision with boosters such as AI-generated image detection or OCR on a receipt, all inside one request instead of three chained services. Moderation, scoring, and gating work identically: one decision, one confidence, one branch point.
Ops and automation teams use the same endpoint for physical-world decisions. Quality control on production lines asks for a score on an ordered defect-severity scale or a box around a suspect region. Warehouse and traffic monitoring run sustained decision loops, which is precisely where WebSocket sessions and deterministic answers earn their keep — a monitoring pipeline that flips its answer between identical frames is worse than no automation at all. And for AI agent builders, the pattern is direct: agents call the endpoint to decide before acting, so a refund, escalation, or dispatch step is gated by a typed choice with a confidence attached rather than by a generated rationale the agent then has to interpret. Tuning thresholds against a labeled slice of historical traffic before rollout is the practical way to land any of these workflows, since the calibration is what makes the numbers governable.
