Perplexity has added optional web searches and page fetching to its automated decision service, according to its November 2026 API changelog. For operations and product teams, this lets software consult public information, such as a supplier’s product page, before returning a decision. The entries give a month, not an exact launch day.
The Decisions API is a software interface, not a chat feature: it returns probabilities for yes/no questions, choices or scores, rather than written explanations. Perplexity’s support-ticket guide says existing API keys work without a separate Decisions signup. Teams must still define what the answers mean and what happens next.
Choose the evidence before the model
The useful starting point is the fact your business needs to establish:
A fact in your own records. For a ticket category or a customer’s account status, use the relevant supplied record. Public search cannot replace missing private account information. Perplexity’s ticket example illustrates classification from supplied content.
A changing public statement. Web evidence can help check what a supplier currently advertises. For example, “Does this plan’s page list data export?” is narrower than “Will this product meet our needs?” The latter also requires your requirements and evidence beyond a vendor’s statement.
Evidence from specified sources or dates. Consider retrieving material separately, inspecting it, then supplying the accepted passages to the decision step. Perplexity’s separate Search API offers domain and publication/update-date filters. Those controls are not extra settings for the built-in Decisions search.
Retrieval also cannot settle an unclear rule. RohitAI’s guide to defining human rules for AI image filters explains that separate problem: people must first agree on what should count.
Check the evidence separately from the answer
According to the API reference, if all searches fail or produce no results, the model can still answer from the information supplied, including any successfully fetched page. A returned decision therefore does not establish that a web check succeeded.
In a grounded response, search_results is empty when no search evidence was added; fetched_results is absent when no usable page text was fetched. Check both fields: an empty search list can coexist with a useful directly fetched page.
Search evidence is pooled by URL. The practical implication is to check support for each question, not simply whether the response contains a source. If required public evidence is missing, route the result for review rather than treating it as a verified yes or no.
Perplexity’s confidence definitions describe calculations from answer probabilities, not a separate audit of sources. A high score should not override missing, irrelevant or outdated evidence.
A fresh fetch is not necessarily a current fact
To fetch a particular page, the guide requires web-grounding mode and a page URL alone as the supplied text. Mixing the URL into an ordinary sentence does not trigger that direct fetch.
The max_staleness setting limits time since the fetched page was crawled. An older cached copy triggers a fresh crawl; omitting the setting leaves the cache age unrestricted. It does not filter search results.
That distinction matters for a product check. A page retrieved today can repeat an old announcement. Check the statement’s effective date, product version and region as well as when the page was acquired.
Also review what you send: search queries include the question and the beginning of the supplied content, which go to Perplexity Search. Do not assume grounding keeps that content out of retrieval queries.
Budget for retrieval as well as tokens
Perplexity’s published prices, checked on November 4, list US$0.001 per completed search and US$0.001 per successful page fetch. Standard v1.2 input costs US$0.02 per million tokens; Flash v1.2 costs US$0.01. Output tokens are free. Retrieved text counts as input.
Illustrative calculation, not an observed bill: assume 100 distinct completed searches, one successful page fetch and 50,000 billed input tokens on standard v1.2, with no retries.
Component | Cost in US dollars |
|---|---|
100 searches × $0.001 | $0.100 |
1 successful page fetch × $0.001 | $0.001 |
50,000 input tokens ÷ 1,000,000 × $0.02 | $0.001 |
Total for these assumptions | $0.102 |
The search portion alone is $0.10. This excludes integration and human-review costs. Grounded requests accept up to 100 questions, but identical generated queries share a search, so question count need not equal billed search count.
A completed search is charged even if it finds nothing; failed or timed-out searches are not. Completed retrieval remains billable if the decision request subsequently fails. These billing rules mean an empty source list is not evidence of zero retrieval cost.
Flash’s lower token rate does not guarantee a cheaper batch. The model guide says standard v1.2 shares supplied content within a question group, while Flash counts it separately for each question. Compare the billed input, not just the rate.
Before commissioning an integration, write one precise question, identify acceptable evidence and decide who reviews unsupported results. Use supplied records for internal facts, built-in grounding for public checks whose sources you can assess, and separate retrieval when source selection needs tighter control. That choice is more useful than a confidence cutoff alone.