Decisions API for request routing

Why routing is a natural fit

Routing asks a finite question — which of my queues owns this — and that is exactly what a decision endpoint answers natively. No parsing a queue name out of generated text, no prompt engineering to stop it inventing a fifth queue.

The same call can carry several questions over the same ticket, so queue, urgency, and a needs-review flag all resolve in one round trip for one credit.

• Queue assignment: billing, platform, account, other
• Priority: an ordered score from low to blocking
• Escalation: a noul check on whether a human must look first

Write criteria as queue descriptions

Each option in a choice question takes a short description of what belongs there. Write them the way you would brief a new triage analyst — the descriptions are the routing policy.

Always include an 'other' or 'unclear' option. Giving the model an honest exit keeps ambiguous tickets out of the wrong queue instead of forcing a confident-looking misroute.

One call: queue plus urgency

Send the ticket text as state and ask two questions: a choice for the owning team and a score for urgency. The response gives you answers.team.choice, answers.urgency.score, and a probability for every option on both.

// Route a ticket: ask for team + urgency in one call,
// then gate the automation on confidence.
const res = await fetch("https://decisions-api.net/api/v1/decisions", {
  method: "POST",
  headers: {
    Authorization: "Bearer YOUR_KEY",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "decisions-1",
    state: "Payments fail with a 500 since your last deploy. Enterprise plan customer.",
    questions: {
      team: {
        type: "choice",
        instructions: "Which queue should handle this request?",
        criteria: {
          payments: "Billing, charges, or payment failures.",
          platform: "Deploys, infrastructure, or API errors.",
          account: "Login, SSO, or permissions.",
          other: "Unclear or out of scope.",
        },
      },
      urgency: {
        type: "score",
        instructions: "How urgent is this for the customer?",
        criteria: ["can wait", "normal queue", "needs attention today", "blocking revenue"],
      },
    },
  }),
});
const { answers } = await res.json();

// Illustrative response: answers.team -> { choice: "payments", confidence: 0.84 }
//                        answers.urgency -> { score: 3, confidence: 0.79 } (0 = lowest level)
if (answers.team.confidence >= 0.8 && answers.team.choice !== "other") {
  assignToQueue(answers.team.choice, { priority: answers.urgency.score });
} else {
  assignToQueue("human_triage", { note: "low confidence" });
}

Gate auto-assignment on confidence

The probability distribution is what makes routing safe to automate. A workable default: apply the routing automatically when confidence is 0.8 or higher, and send everything below that to a human triage queue.

Tune the threshold on your own ticket history — the right value depends on what a misrouted ticket costs you versus a delayed one.

Route requests between models

The same pattern picks which model should answer. Ask a choice question with options like fast_model (short factual or formatting requests), strong_model (multi-step reasoning, code, long context) and human (legal, refunds, or anything a model should not answer alone). Every option comes back with a probability, so you can see how contested the pick was.

Gate it the same way: when confidence is low, route the request to a person or a safer path instead of trusting the top option — the runner-up probability tells you how close the call was.

Cost and volume

One successful call costs 1 credit whether you ask 1 or 6 questions. For a backlog of historical tickets, the dashboard batch tool runs the same request shape over a CSV or JSONL file.

FAQ