
Perplexity's API builds a cited answer in two steps: a web search returns results, then a model writes the answer and points to those results by number (Web Search docs). For a brand, the useful part is what the docs show a search result is made of, and which controls a builder can use to include or drop it.
Everything below that comes from Perplexity's documentation is linked to its page. Anything about what a brand should do is our reading, and we say so each time. One limit up front: these are the developer docs. They describe the API, not the Perplexity app on your phone, and they say nothing about how results are ranked.
What the docs describe: two roads and one retired one
The API platform has several APIs behind one key. Two matter for citations (platform overview):
- Search API: ranked web results as JSON, with
title,url,dateand a textsnippet. No model and no generated answer. - Agent API: a finished answer with citations, where the model can use a
web_searchtool.
The older road was Sonar Chat Completions. Its responses carried a citations list of URLs and a search_results list of objects, next to an answer with markers such as [1][2][7] (Sonar quickstart, legacy). The docs now say that Sonar Chat Completions support ended on September 27, 2026, and that synchronous and streaming requests keep working while they are reformulated as Agent API requests (migration overview). So the shape you will meet today is the Agent API's, and we describe that one first.
How an answer gets its sources
In the Agent API, web_search is a tool in the request. The model decides when to call it, based on your prompt and instructions (Web Search docs). The steps, as the docs lay them out:
- The model runs one or more searches. With several reformulated queries, the result budget is split between them (Web Search docs).
- The response can include a
search_resultsitem before the final message. Each result carries anid. - The answer text is a separate
messageitem. The[n]markers sit inside that text, and each one maps to the result whoseidisn(migration guide).
Two details are easy to miss. First, markers are not guaranteed: whether the model adds them "is prompt-dependent", and the docs say to treat each entry's id and url as the source of truth (Web Search docs). The fast, low, medium and high effort levels already include inline citations, numbered like [1] on fast and typed like [web:1] on the others (migration guide). Second, the published default instructions of the fast level tell the model to cite every sentence that uses search information, to cite up to three sources per sentence, and to leave out citations if it did not search (effort levels). By those instructions, a cited sentence is meant to rest on a result the search found (our reading; the markers themselves depend on the prompt).
What a source looks like
Each entry in search_results has seven fields (Web Search docs):
id: the stable index a citation refers tourl: the canonical URL of the source pagetitle: the page title as the source returns itsnippet: excerpted text extracted from the page during searchdate: when the page was first published, asYYYY-MM-DDlast_updated: when it was last updatedsource: where the result came from, for exampleweb
The Search API page adds that snippet is query-relevant text, cut to a token limit, and "can be an empty string"; date and last_updated can be null (Search API overview). The docs do not say why a snippet comes back empty.
The controls a builder holds
A builder who calls the API can narrow where answers come from. This is the part brands rarely see.
| Control | What it does | Limit |
|---|---|---|
search_domain_filter |
Include only the listed domains or URLs, or exclude them with a - prefix |
Up to 20 entries, allowlist or denylist, not both |
search_recency_filter |
Keep results from the past hour, day, week, month or year |
One value |
search_after_date_filter, search_before_date_filter |
Keep results published inside a date window | MM/DD/YYYY |
last_updated_after_filter, last_updated_before_filter |
Filter by when the page was last updated, not first published | MM/DD/YYYY |
search_language_filter (Search API) |
Return only results in the listed languages | Up to 20 ISO 639-1 codes |
user_location (Agent API) or country (Search API) |
Shape results for a country, region or city | Country as a two-letter code |
max_results |
How many results a call collects | 1 to 50 in the Agent API tool; 1 to 20 for Search API web search |
Sources: Web Search docs, Search API overview, domain filter, date filters, language filter.
The domain filter works at domain level (wikipedia.org) or at URL level, and the docs use a .gov entry as an example (Web Search docs). The recency windows map to the past hour, 24 hours, 7 days, 30 days and 365 days.
The filters compose: the docs say there is no per-request limit on combining them (Web Search docs). The sizes of the limits are easier to see than to read.
What a brand can learn (our reading)
The docs do not tell a brand how to get cited. Nothing there lets you submit a page, pay for a place or ask for inclusion. What they show is the machinery. Reading it, we would draw five conclusions, and none of them is a Perplexity promise.
- Write for the snippet. The
snippetis text extracted from the page for the query. A page that states its answer plainly near the top gives that extraction something to work with. We have not tested how Perplexity picks the text. - Keep a real title.
titleis returned as the source gives it, and it is what a reader sees next to the marker. - Date pages honestly and update them.
dateandlast_updatedare fields, and the date and recency filters act on them. The docs do not say how a page with anulldate is treated under a filter, so do not count on it. - Expect several searches for one question. The model may reformulate. Cover the nearby phrasings of a question on the page, not only one.
- Publish in your customers' language. The Search API has a language filter, so a builder can limit a Turkish question to Turkish results. A Turkish buyer needs a Turkish page.
For an agency, the practical step is to look, not guess. Run your category's questions through the Search API or an Agent API call with web_search, and read which url values come back, at what dates, and with what snippet. The docs price web_search at $2.50 per 1,000 invocations, or $1.00 with search_type: "fast", plus model tokens (Web Search docs). A script that does this is a fair job for a tool like Claude Code. For the wider picture across assistants, see how products show up in AI answers.
What we cannot tell you
- How results are ranked. The Search API pages call its results "ranked" and stop there.
- Whether the Perplexity app uses the same settings as the API. The docs describe the API, and they say the grounded search once built into Sonar is now available as the
web_searchtool (migration guide). - How often a given site is cited. No figure in these pages speaks to that, so we give none.
Being cited is only half of the work. The page a reader lands on, or the ad that follows, still has to hold up: you can check an ad's creative before you spend with the free creative score. If your products live in a feed and you want finished ads from it, that is what Framepx does: an AI system that turns product feeds into ads (how it works).
FAQ
Does Perplexity always cite sources?
Not by rule. In the Agent API, markers depend on the prompt, though the fast, low, medium and high effort levels include citation instructions by default (migration guide). The fast level's instructions say to skip citations when no search was run (effort levels).
Is [1] the top search result?
The docs say [n] maps to the result whose id is n. They do not say that id 1 is the best result.
Can I pay or submit my site to be cited? The docs describe no such option. The controls they list belong to the developer who calls the API.
Is Sonar still the way to get citations? Support for Sonar Chat Completions ended on September 27, 2026, and the docs recommend the Agent API for all new projects (migration overview).
Sources
Written by
Framepx team, Editorial team
The Framepx editorial team writes for brands, marketers and agencies about ad platforms, measurement, creative and product feeds.


