Most teams that add a language model to a product end up writing the same integration twice. First they write the prompt, then they write a parser that desperately tries to coerce free-form text back into the shape the application actually needs. The model answers “yes, probably, though it depends on the region” and your regex finds nothing, and somewhere an on-call engineer gets paged at 2 a.m. A decision API exists to delete that second piece of code entirely.
At its core, a decision API is an HTTPS endpoint that accepts structured state — text, JSON, images — together with a set of questions defined in your source code, and returns typed, schema-valid answers instead of prose. You are not asking a model to explain itself and then interpreting the explanation. You declare the decision shape you need in advance: one of these five labels, a level on this ordered scale, a probability between 0.00 and 1.00, a numeric value on a grid, or a location inside an image. The response arrives in that shape, every time, in a single pass.
That distinction matters more than it first appears. Chat models produce tokens; decision APIs produce decisions with a contract. The answer types map directly onto the primitives engineers already use to branch logic. A choice answer returns exactly one of your labels —refund, exchange, escalate — so it can drive a switch statement without validation. A score answer returns a level on an ordered scale, which is what you want for severity, priority, or risk tiers where the ordering carries meaning. A truth answer returns a calibrated probability, the kind of number you can feed into a threshold, a queue weight, or an expected-value calculation. A number answer places a value on a grid, and point and box answers return coordinates inside an image for spatial questions.
The property that separates this from a decorated prompt is calibration. Every answer carries a confidence that is meant to be read literally: when the endpoint says 0.82, roughly 82 out of 100 comparable cases should be correct. That turns confidence from a decorative field into a control-flow primitive. Code can act instantly above a threshold and take a re-check or safe path below it. And because these systems are deterministic — the same request produces the same answer — you can write tests against them, replay production traffic, and reason about regressions the way you would with any other pure function. “Reply in JSON” gives you none of that: no guaranteed schema, no meaningful probability, high and variable latency, and a bill that scales with verbosity.
Inside the Request/Response Contract: State In, Typed Answers Out
Platforms such as decisionnode.com implement this pattern around a deliberately small surface. A single HTTPS endpoint, POST /v1/decide, accepts the current state as text, JSON, or up to 16 images or video frames, alongside the questions you have defined in code. You get back schema-valid typed answers in one pass — no multi-step reasoning loop, no second round trip to extract structure, no prompt engineering treadmill when the payload changes.
The practical consequence is that your questions become part of your codebase rather than part of a string. A routing service declares that it needs a choice over a fixed label set and a truth probability for whether the ticket mentions a billing dispute. A warehouse service declares that it needs a point in the frame where a pallet is sitting. The contract is versioned, reviewed, and tested like any other interface — which is precisely how you want a component that sits in the hot path of order, payment, or safety logic.
Confidence handling deserves its own line of design. The most common production pattern is a three-band threshold: above the upper bound, the system acts autonomously; between the bounds, it enriches the request with more context (an extra frame, a retrieved record) and re-decides; below the lower bound, it routes to a human queue or a conservative default. Because confidence is calibrated rather than merely present, those bands can be tuned against real acceptance rates instead of guesswork.
Latency and cost shape what is feasible here. DecisionNode offers 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, priced at $0.042 per 1M input tokens. Output tokens are always free, batch discounts are available, and there is a free daily tier for development. Those numbers sit comfortably inside a synchronous request path — the kind of budget where a decision API can replace a hand-written rule table without adding a noticeable tail to p95 latency.
Integration is intentionally boring. SDKs cover TypeScript, Python, Go, Ruby, and plain curl, with MCP tools for agent runtimes and webhooks for async flows. For workloads that exceed roughly 10 decisions per second — drones, robots, simulators, continuous machine monitoring — sessions over WebSocket remove per-request overhead and let you stream state frames while receiving decisions continuously. Optional boosters add specialised capability where a general decision model benefits from a focused one: human age estimation, AI-generated image detection, face detection and recognition, OCR, depth, and segmentation.
Shipping a Decision API: Patterns, Guardrails, and Real Workloads
The teams that get the most out of a decision API treat it as an infrastructural component rather than a feature. That means the confidence threshold lives in configuration and is monitored, not hardcoded in a controller. It means every decision is logged with its input hash, question version, answer, and confidence, so that drift is visible as a metric rather than a surprise. And it means the label taxonomy is owned by someone — because adding a sixth routing label silently changes the meaning of the previous five, and a decision engine will faithfully return the new label for cases that used to map elsewhere.
The workload fit is broad because the underlying primitive is broad. Ticket routing and triage use choice plus truth to classify and prioritise inbound requests. Fraud and promo-abuse checks use calibrated probabilities to gate transactions and stack risk signals in a way a rules table cannot express. Order and shipping decisions use score answers to place exceptions on a tiered handling scale. Moderation and gating use the same confidence bands to auto-approve, auto-reject, or defer. On the physical side, quality control on production lines, warehouse monitoring, and traffic monitoring lean on point and box answers against camera frames, with WebSocket sessions handling the frame rate.
Agent builders are a newer and quickly growing consumer. An AI agent that must choose a tool, confirm a user’s intent, or verify that a screenshot shows what it claims has a recurring need: a fast, typed, calibrated answer before it acts. Wiring that to a decision API turns an open-ended generation step into a bounded check with a confidence value attached, which is far easier to constrain than asking the agent to grade itself in prose. Combined with MCP tooling and webhooks, the decision endpoint slots into an agent loop the same way a validation function slots into a normal service.
Three operational habits pay off repeatedly. First, batch aggressively — high-volume offline scoring for backfills, audits, and threshold tuning is dramatically cheaper than single-call traffic and gives you the labelled sample you need to validate calibration. Second, keep questions narrow: a decision endpoint asked for one thing returns a sharper signal than one asked for twelve at once, and narrow questions are individually versionable. Third, build a shadow path — run the decision API alongside the existing rule engine for a period, compare outputs, and let the disagreement rate tell you where the rules were wrong. Determinism makes that comparison meaningful, because the same request always yields the same answer and any divergence is attributable to a deliberate change rather than run-to-run noise.