Perplexity's Decisions API evaluates supplied content and returns typed predictions with probabilities. You provide state and questions, then use the answers to classify content or choose an application action. Its model, pplx-decider-v1-27b, accepts text and images. Your code defines what happens after the prediction.
For example, a support application could combine a customer's message with a screenshot to suggest a queue. The application might accept a clear billing prediction and send an ambiguous case to a person. That review policy belongs in your application, where you can test and change it independently of the model.
Copy link to headingHow does the API work?
Each request separates the evidence from the questions. The state contains the material to evaluate, such as a ticket or an application record. The questions map defines what you want to know about it. Answers come back under the names you assigned to those questions.
This separation helps when several parts of a workflow need the same evidence. For a support ticket, you might want a destination queue and a separate indication of whether the customer explicitly requests a refund. Those questions describe different properties of one record. Treating them separately prevents a routing label from also having to encode refund intent.
The decision-model approach suits tasks with defined outcomes. Before writing a question, decide which answers your application can use. If every possible answer leads to the same action, the question may not belong in that workflow.
Copy link to headingWhat kinds of questions can you ask?
Perplexity supports three question types:
Use a Choice when the outcomes are categories. Billing and account access are different destinations, so assigning numbers to them would imply an order that doesn't exist. Use a Score when the levels have a meaningful sequence, such as missing reproduction steps, partial steps, and complete steps.
For that three-level rubric, a score between two levels represents a weighted result across the levels. It doesn't create a new rubric description. If your interface needs a label, define how it converts the result and retain the distribution for cases near a boundary.
Noul fits a separate yes/no property. Keep the question precise enough that two reviewers could label the same example consistently. “Does the customer explicitly request a refund?” is narrower than “Should we refund the customer?” The latter also requires the refund policy, transaction status, and whatever authorization checks your product enforces.
Copy link to headingHow do you make a request?
The following Node.js example asks about a ticket's destination and refund intent. It uses an invented ticket and prints the returned answers; it doesn't issue a refund or move a ticket.
Set PERPLEXITY_API_KEY in your server environment, save the code as decisions.mjs, and run node decisions.mjs using Node.js 22 or later.
const apiKey = process.env.PERPLEXITY_API_KEY;if (!apiKey) throw new Error("Set PERPLEXITY_API_KEY before running.");
const response = await fetch("https://api.perplexity.ai/v1/decisions", { method: "POST", headers: { Authorization: `Bearer ${apiKey}`, "Content-Type": "application/json", }, body: JSON.stringify({ model: "pplx-decider-v1-27b", state: { subject: "Charged after cancellation", message: "I canceled last week, but another charge appeared. Please refund it.", }, questions: { queue: { type: "choice", instructions: "Which queue should investigate the customer's main issue?", criteria: { billing: "Charges, invoices, or refund requests.", account_access: "Difficulty signing in or recovering an account.", other: "Any issue outside these categories, or insufficient evidence.", }, }, refund_requested: { type: "noul", instructions: "Does the customer explicitly request a refund?", }, }, }), signal: AbortSignal.timeout(30_000),});
if (!response.ok) { throw new Error(`Decisions request failed with HTTP ${response.status}`);}
const { answers } = await response.json();console.log(answers.queue);console.log(answers.refund_requested);Inspect the returned answers before connecting them to actions. The sample's other option gives the model somewhere to place an issue outside the specialist queues or a ticket that lacks enough information to route. In a larger support workflow, separate those cases if they need different follow-up steps.
Copy link to headingHow should an application use the probabilities?
The selected Choice is the highest-probability option, but being first doesn't necessarily make it a useful automatic decision. In an illustrative distribution of 0.46 for billing, 0.44 for account access, and 0.10 for other, billing wins by a narrow margin. These numbers are an example, not an observed result from the request above.
Your application could send that case for review. To select a threshold, label representative tickets and check how often the accepted predictions send them to the correct queue. Examine the cases you would automate separately from those you would hold back. An overall accuracy figure can hide a poor result in a less common queue.
Choice and Score answers also include confidence, which differs from an individual option's probability. Use the specific returned field your policy was tested against. Substituting confidence for an option's probability changes the rule, even though both values fall between zero and one.
If a wrong route only adds a manual reassignment, your acceptance policy may differ from one that starts a consequential action. Keep transaction permissions and eligibility rules in code. Predicting that someone requested a refund doesn't establish that the refund is authorized.
If you're evaluating an existing Jev workflow, compare Jev and Perplexity's Decisions API using the same cases and routing policy.
Copy link to headingWhat does image support make possible?
Images let you evaluate visible evidence alongside the customer's description. Consider “I can't get past this screen” with an attached payment error. The message alone gives little basis for routing. The screenshot can supply the missing context.
The same design can apply to other bounded visual tasks. In a catalog workflow, you could ask whether a submitted photograph shows the required product view. For bug-report intake, the question could identify which application screen appears in an attachment. Include an outcome for insufficient evidence so a blurred or unrelated image doesn't have to become a confident-looking category.
Decide what the visual prediction will change before collecting more images. For the support example, suggesting a queue needs less evidence than diagnosing the underlying payment failure. The latter may require logs or account records that a screenshot cannot supply.
Build a support screenshot classifier with Perplexity to try image preparation and a review threshold in code.
Copy link to headingCan you run the model yourself?
Perplexity publishes the model weights under Apache 2.0, along with Python inference code. This provides a separate path for running predictions on infrastructure you operate.
Self-hosting changes the work your team owns. You need to provision the model, build the serving application, and test how it handles your workload. The provided local inference interface also differs from the hosted HTTP request, so treat the two implementations as separate integrations.
Copy link to headingWhat should you use another tool for?
The Decisions API returns bounded predictions. Use a generative model when the product needs a written support reply or an explanation for the customer. If a decision depends on current account facts, retrieve those facts before evaluation rather than asking the model to infer them from the customer's message.
Defined outputs don't resolve missing evidence or conflicting policies. When reviewers cannot agree on a label, clarify the category definitions before tuning a threshold. Your evaluation dataset should include those disputed cases so the application has a deliberate way to handle them.
Copy link to headingFrequently asked questions
Copy link to headingIs Perplexity's Decisions API a chat API?
No. The Decisions API evaluates content against questions with defined answer types. Use a conversational model when you need a generated response for a person to read.
Copy link to headingWhat does Noul mean in a decision request?
Noul is the yes/no question type, with a numeric answer representing the probability of yes. The application chooses how to interpret that number, including when to ask for human review.
Copy link to headingDoes a decision model explain why it chose an answer?
The Decisions API does not generate a written rationale. If your workflow needs an explanation, design that as a separate step and distinguish the explanation from evidence that the prediction is correct.
Copy link to headingAre Perplexity's decision-model weights available?
Yes. Perplexity publishes the weights for pplx-decider-v1-27b and example inference code. Running them yourself also means operating and validating your own model-serving setup.