If you need to know how to use Perplexity AI Sonar via API in September 2026, the practical answer has an unusual deadline attached: Sonar can still serve web-grounded answers with citations today, but Perplexity says its Sonar tiers retire on 27 September 2026. I would therefore build the request correctly now, while treating every new line of integration code as transitional. That single change in context makes most older Sonar tutorials incomplete, even when their Python examples still run.
The working path is straightforward. Create an API key, use the Perplexity SDK or an OpenAI-compatible client, send a chat-completions style request to the Sonar service, then read the generated answer alongside the top-level citation and search-result fields. The important production work comes after the first response: select a model by workload, control search with request parameters rather than prose, log the cost object, respect tier-specific rate limits, and isolate the provider-specific response shape behind a small adapter so the later Agent API switch does not leak across your application.
This guide is deliberately different from a conventional quick-start. It explains the canonical endpoint and compatibility alias, the retrieval behaviour most prompting guides miss, current token plus request-fee pricing, rate-limit ceilings, citation handling, and the migration traps documented by Perplexity itself. I also separate what is verified in official documentation from what cannot be claimed without live account telemetry. The result is a Sonar guide you can implement now without designing yourself into a dead endpoint three weeks later.
How to Use Perplexity AI Sonar via API in 2026
Sonar is Perplexity’s web-grounded answer API. The model retrieves current web material, synthesises an answer and returns source information with the response. Perplexity’s current quick-start describes four API families: Agent API for agentic and multi-model work, Search API for raw ranked web results, Sonar for cited answers, and Embeddings for vector representations. That division matters because Sonar is not a generic search endpoint and it is not merely a chat model with an optional browser tool.
For the architectural background, our Perplexity API infrastructure guide explains why cited, live-web responses are a different system design from a conventional model-only completion. In this implementation, that distinction shows up in three places: retrieval happens before answer generation, sources are returned as structured response data, and search context itself is a billable component.
Perplexity’s OpenAI compatibility documentation now makes the route distinction explicit. POST /v1/sonar is the canonical Sonar endpoint. POST /chat/completions is accepted as an alias for OpenAI SDK compatibility, so an existing OpenAI client can call client.chat.completions.create() after changing the base URL and credential. For new code, the official Perplexity SDK is the cleaner choice because its types expose Perplexity-specific fields directly and do not depend on a compatibility layer.
| Integration Style | Request Surface | Best Fit | September 2026 Note |
| Perplexity SDK | client.chat.completions.create() | New Sonar code that must run now | Type-safe Sonar fields; plan migration to responses.create(). |
| OpenAI SDK | /chat/completions alias | Existing OpenAI-style applications | Keep the client style, but migration later moves to Responses API semantics. |
| Raw HTTP | POST /v1/sonar | Framework-free services and debugging | Canonical Sonar route; easiest place to see the wire contract. |
| Agent API | POST /v1/agent | New production applications | Perplexity recommends this for new applications; Sonar retires 27 September. |
Create and Protect the API Credential
Start in the Perplexity API Platform, create the required API group if your console asks for one, then generate an API key. Perplexity’s key-management documentation warns that a new key is shown once, so treat the creation screen as a secret-handling event, not a copy-and-paste convenience. Put the key in a server-side secret store or environment variable. Do not ship it in JavaScript delivered to a browser, a mobile binary, a public Git repository or a WordPress front end.
Our Perplexity API key guide covers credential purpose and lifecycle in more detail. For a production application, I would create separate keys for development, staging and production, then rotate or revoke one environment without forcing every deployment to change at once. Perplexity also supports multiple keys, which makes that separation practical.
The SDK examples below assume PERPLEXITY_API_KEY is already available in the process environment. That gives local development and cloud deployment the same code path. The official Python package is perplexityai, while the TypeScript package is the Perplexity SDK published for Node.js. OpenAI libraries also work for Sonar compatibility, but using Perplexity’s own SDK reduces ambiguity around fields such as search filters and response metadata.
# Python
python -m pip install perplexityai
# macOS/Linux shell
export PERPLEXITY_API_KEY=”replace-with-your-secret”
One operational detail is easy to overlook: consumer Perplexity subscriptions and API billing are separate surfaces. A Pro, Max or enterprise workspace should not be treated as an unlimited developer quota. API credits and cumulative API spend determine the published usage tier and therefore the rate limits discussed later in this guide.
Build the First Sonar Request
How to Use Perplexity AI Sonar via API With Python
The shortest current Python example uses the native Perplexity client. The call keeps retrieval simple, selects the base sonar model and passes a user message. Because Sonar is a search-grounded service, the question should contain the terms that you actually want the search layer to retrieve. Avoid hiding critical search constraints in a system message.
from perplexity import Perplexity
client = Perplexity()
response = client.chat.completions.create(
model=”sonar”,
messages=[
{
“role”: “system”,
“content”: (
“Use only retrieved evidence. If the evidence is insufficient, “
“say so instead of guessing.”
),
},
{
“role”: “user”,
“content”: (
“Summarise UK AI regulation changes announced in the past 30 days. “
“Return five material changes and explain which organisations are affected.”
),
},
],
search_recency_filter=”month”,
search_language_filter=[“en”],
web_search_options={“search_context_size”: “low”},
)
print(response.choices[0].message.content)
print(response.citations)
print(response.search_results)
print(response.usage.cost)
If you are using Sonar as part of a coding workflow, our Perplexity coding guide gives a broader view of where generated code, documentation retrieval and verification should sit. The API-specific rule is simpler: log the response metadata from the beginning. A prototype that prints only message content throws away the very citation and cost signals that make Sonar operationally useful.
OpenAI SDK users can keep the chat-completions calling pattern today. Set the Perplexity base URL through configuration and use the Perplexity key, then call client.chat.completions.create() with a Sonar model name. Perplexity’s compatibility guide says the SDK will route to /chat/completions, which the service accepts as an alias. Do not hard-code an assumption that the alias is the canonical long-term endpoint, because the migration to Agent API changes the request surface.
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ[“PERPLEXITY_API_KEY”],
base_url=os.environ[“PERPLEXITY_API_BASE”],
)
completion = client.chat.completions.create(
model=”sonar-pro”,
messages=[
{“role”: “user”, “content”: “Compare the latest two UK AI policy updates.”}
],
)
print(completion.choices[0].message.content)
Read the Response as a Source Contract
A Sonar response is more than generated prose. The current documentation exposes the normal chat-completions choice plus top-level citations, structured search_results and usage details. In production, I would treat those fields as a source contract: content is the answer shown to a user, citations are the source identifiers associated with that answer, search_results preserve richer result metadata, and usage.cost is the accounting signal that should feed application telemetry.
Do not ask the model to invent source URLs inside its prose. Perplexity’s prompt guide explicitly says the language-generation component does not have the original URLs in the way the response wrapper does. The accurate source data is returned separately. Rendering links from search_results or citations therefore avoids a common failure mode in which an otherwise grounded answer contains a model-generated URL that was never actually retrieved.
This distinction also matters when discussing Perplexity AI accuracy. A citation proves that a source was retrieved and attached; it does not by itself prove that every sentence in the synthesis is entailed by that source. For high-stakes applications, validate that cited evidence supports the specific claim, check source freshness, and surface uncertainty when results are sparse or mismatched.
A useful normalisation layer can keep the rest of your application independent of Perplexity’s response shape. The adapter below turns the provider response into four fields your product can own. That same interface can later accept Agent API search results without forcing every controller, queue and UI component to understand a new vendor schema.
def normalise_sonar(response):
return {
“answer”: response.choices[0].message.content,
“citations”: list(getattr(response, “citations”, []) or []),
“search_results”: list(getattr(response, “search_results”, []) or []),
“cost”: getattr(getattr(response, “usage”, None), “cost”, None),
}
That adapter is deliberately boring. Boring provider boundaries are valuable because the expensive part of a migration is rarely changing one HTTP route; it is finding provider-specific assumptions scattered through analytics, caching, error handling, tests and front-end rendering.
Control Retrieval Instead of Over-Prompting It
The most important Sonar prompting detail is structural. Perplexity says Sonar performs its web search before generation and only the user message drives that search. The system prompt is not visible to the search step. It reaches the model after results are already in hand. That means a beautifully written system instruction such as ‘search only official sources from this month’ cannot rescue a vague user query or enforce retrieval constraints.
Use the user message to describe the information need, and use request parameters to constrain the retrieval layer. Current Sonar filters include allowlist or denylist domain filtering with up to 20 domains or URLs, publication-date and last-updated filters, recency values such as hour, day, week, month and year, language filtering for up to 10 ISO 639-1 codes, location controls, academic mode, SEC mode, and low, medium or high search context. Academic mode has a documented edge case: date filters are silently ignored, so the desired time period has to be expressed in the query itself.
The search_context_size option is particularly important because it changes both retrieval depth and the request fee. Low is the default and cheapest. Medium trades cost for broader evidence. High is the most expensive and should be reserved for questions where additional retrieved material materially improves the answer. Perplexity also documents enable_search_classifier and disable_search controls, but turning search off does not reduce the published pricing for a Sonar request, so it should be used for behaviour or latency, not as a cost-saving trick.
Sonar Pro also has Pro Search, which adds multi-step tool use and dynamic research. It only operates in streaming mode. Setting search_type to pro while stream is false falls back to standard Sonar Pro behaviour. That is a classic integration trap because the request can succeed while silently delivering a less capable execution path than the developer intended. If a production feature depends on Pro Search, assert both settings in tests rather than assuming the model name implies the research mode.
Choose a Model by Workload and Cost
Perplexity currently lists four Sonar families. Standard Sonar is a non-reasoning model with a 128K context window and is optimised for quick grounded Q&A. Sonar Pro expands the context to 200K and is described as returning twice as many search results as standard Sonar. Sonar Reasoning Pro uses a 128K context with multi-step reasoning. Sonar Deep Research also has a 128K context and is designed for exhaustive research across many sources. The old sonar-reasoning model was removed in December 2025, so examples that still use that slug are stale.
Model selection should start with the minimum behaviour required by the product. A current-status widget rarely needs Deep Research. A detailed regulatory comparison may justify Sonar Pro or Reasoning Pro. A long research report can justify Deep Research, but its billing includes more meters and its rate limits are much lower. The official pricing matrix below is the safer planning baseline than third-party summaries that quote only token rates.
| Model | Context | Input / 1M | Output / 1M | Additional Request or Research Fees |
| Sonar | 128K | $1 | $1 | $5 / $8 / $12 per 1K requests for low / medium / high context. |
| Sonar Pro | 200K | $3 | $15 | $6 / $10 / $14 per 1K standard requests; Pro Search can rise to $14 / $18 / $22. |
| Sonar Reasoning Pro | 128K | $2 | $8 | $6 / $10 / $14 per 1K requests for low / medium / high context. |
| Sonar Deep Research | 128K | $2 | $8 | $2 per 1M citation tokens + $5 per 1K search queries + $3 per 1M reasoning tokens. |
Matiss Katanenko, co-founder of Honeyb, summarised the commercial trap neatly in June 2026: “Sonar pricing has two parts, and the second one trips people up.” The official pricing page confirms that normal Sonar, Sonar Pro and Sonar Reasoning Pro combine token costs with a request fee determined by search context. The base Sonar example in Perplexity’s own documentation, using 500 input tokens and 200 output tokens, costs $0.0057 at low context, $0.0087 at medium and $0.0127 at high. The request fee dominates that small query.
Perplexity CEO Aravind Srinivas has also framed infrastructure adoption in terms of API distribution. In a 2026 developer-event post he wrote that “Perplexity’s APIs … are being used in all Samsung devices and some of the Mag 7 companies as of today.” That is not a performance benchmark, but it is a useful reminder that API economics and reliability matter at device and enterprise scale, not only in developer demos.
Price a Real Request Before Production
A practical Sonar cost model is request fee plus input tokens plus output tokens, with additional Deep Research meters where applicable. Consider a standard Sonar call with low search context, 1,000 input tokens and 600 output tokens. Token cost is $0.0010 plus $0.0006, while the low-context request fee is $0.005. Total cost is about $0.0066 for that call. At 100,000 similar requests, the rough bill is $660 before any differences in token count or search context.
Now move the same workload to Sonar Pro at low context with the same 1,000 input and 600 output tokens. The input cost is $0.003, output cost is $0.009, and the request fee is $0.006, for about $0.018 per request. The important insight is not the exact example. It is that a team that monitors only token totals can miss a major part of the bill, while a team that records the returned cost object can attribute spend by route, tenant, feature and query class.
For Pro Search, cost can change again because the request fee differs between fast and pro modes. The current documentation lists fast Sonar Pro requests at $6, $10 and $14 per 1,000 for low, medium and high context. Pro Search is $14, $18 and $22. Auto classification bills whichever path actually triggers. If you expose an ‘auto’ research feature, budget with observed routing distributions rather than assuming every query is charged at the lower fast-search rate.
This is also where competitors can be a better fit. If you need raw ranked web results and already have a model that performs synthesis, Perplexity’s Search API is $5 per 1,000 successful search requests with no token charge on that endpoint. Vellum’s June 2026 industry comparison makes the same architectural distinction: Sonar is strongest when you want a citation-ready answer, while raw-search products provide more control over retrieval and downstream reasoning. The right choice is workload-specific, not a universal endorsement of Sonar.
Rate Limits, Retries and Production Failure Modes
Perplexity’s usage tiers are based on cumulative API credit purchases across the account lifetime, not the current credit balance. Tier 0 begins at $0 in purchased credits, Tier 1 at $50, Tier 2 at $250, Tier 3 at $500, Tier 4 at $1,000 and Tier 5 at $5,000. The documentation says a reached tier is retained permanently. Those tiers change the published Sonar and Agent limits, while Search API uses a separate fixed limit.
For the capacity mechanics behind those numbers, see our Perplexity API rate-limit guide. The main production rule is to model each API family independently. A single global throttle can under-use Search API while still overwhelming Deep Research, because their ceilings differ by orders of magnitude.
| Tier | Credits Purchased | Sonar / Pro / Reasoning Pro | Deep Research | Agent API |
| 0 | $0 | 50 RPM | 5 RPM | 1 QPS, 50/min |
| 1 | $50+ | 150 RPM | 10 RPM | 3 QPS, 150/min |
| 2 | $250+ | 500 RPM | 20 RPM | 8 QPS, 500/min |
| 3 | $500+ | 1,000 RPM | 40 RPM | 17 QPS, 1,000/min |
| 4 | $1,000+ | 4,000 RPM | 60 RPM | 33 QPS, 2,000/min |
| 5 | $5,000+ | 4,000 RPM | 100 RPM | 33 QPS, 2,000/min |
The published limiter uses a leaky-bucket design, so capacity refills continuously. Do not write retry logic that sleeps until an imagined next-minute reset. Use a shared queue, exponential backoff with jitter, a bounded retry count and an overall request deadline. A 429 is a flow-control signal, not permission for every worker to retry at once.
When throttling is already happening, our Perplexity API 429 fixes separate burst pressure, tier ceilings, billing problems and upstream incidents. That distinction belongs in production observability too. Log endpoint, model, attempt number, latency, status, tenant and cost so an operator can tell whether a spike is local concurrency, an exhausted allowance or a service-side event.
Finally, fail closed on citation-critical use cases. If the request succeeds but the evidence list is empty or materially irrelevant, do not silently present the answer as sourced. Perplexity’s own prompt guidance recommends explicitly allowing the model to say it found insufficient evidence. That makes a ‘no reliable answer found’ state a valid product outcome rather than an exception the model feels compelled to fill with training-data guesses.
Sonar, Search API or Agent API?
The September 2026 decision is no longer simply which Sonar model to choose. Perplexity recommends Agent API for new applications and says Sonar retires on 27 September. Search API remains useful when you want retrieval without synthesis. In other words, the cleanest architecture chooses the API by contract: answer, results or agent loop.
| API | Returns | Web Behaviour | Pricing Shape | Use It When |
| Sonar | Synthesised answer + citations + search results | Search is built into the answer flow | Tokens + request fee; Deep Research adds meters | Maintaining an existing cited-answer workflow before retirement. |
| Search API | Raw ranked result objects | Direct search without LLM synthesis | $5 per 1K successful requests, no token fee | You own ranking, RAG, extraction or downstream model choice. |
| Agent API | Agent response with tools, presets and multi-provider models | Search is available through tools or presets | Model tokens + tool invocations | New applications, multi-step workflows and post-Sonar migration. |
Search API is especially attractive for pipelines that already have an LLM layer because it does not force you to pay for a second synthesis step. It supports ranked web results, filtering, multi-query search and structured fields such as title, URL, snippet, date and last_updated. Sonar is more convenient when the product wants the answer and sources in one call. Agent API becomes the strategic choice when the application needs repeated tool use, model routing, URL fetching, reasoning controls or a surface Perplexity intends to keep after the Sonar retirement date.
If your roadmap is already agentic, our AI agent with Perplexity guide is the natural next layer. The key migration principle here is to keep orchestration outside the Sonar-specific adapter now, so the agent transition becomes a provider change rather than an application rewrite.
There is also a reason to prefer direct API contracts over loading every possible tool through a general protocol. At Perplexity’s Ask 2026 event, CTO Denis Yarats was reported as calling the internal MCP approach “too expensive for production” while the company moved some internal workflows toward APIs and CLIs. Y Combinator CEO Garry Tan amplified the same concern, writing: “It eats too much context window.” Those comments are about tool-interface overhead, not a blanket rejection of MCP, but they reinforce a practical rule: keep production tool surfaces narrow, measurable and demand-loaded.
The September 27 Migration Window
Perplexity’s current Agent API announcement is unusually explicit: Sonar endpoints remain available today, but the Sonar tiers retire on 27 September 2026, when Agent API becomes the main surface for this work. As of 8 September, that leaves 19 days. If nothing changes by the retirement date, Perplexity says Sonar calls will stop working. That makes migration part of the implementation, not a separate future maintenance task.
The official migration skill gives different instructions depending on integration style. Raw HTTP callers should keep raw HTTP and move the endpoint to POST /v1/agent. OpenAI SDK users should keep the OpenAI SDK, use a base URL that includes /v1, upgrade to a recent OpenAI package and switch from chat.completions.create() to responses.create(). Perplexity SDK users should keep the same client and environment key but move from chat.completions.create() to responses.create(). Framework integrations such as LangChain and LlamaIndex need their own bridge changes rather than a blind URL replacement.
The migration is not only syntax. Agent API does not automatically reproduce every Sonar assumption. Perplexity’s migration guidance warns that strict request validation can reject leftover Sonar-only fields with a 400. Search must be made explicit through a preset or web_search tool. Citation and search-result placement changes from top-level Sonar fields to output items in the Agent response. Agent responses can also arrive over HTTP 200 with a status such as failed or cancelled, so production code must branch on response status rather than treating every 200 as completed work.
Streaming has a similar contract change. A Sonar stream is often handled as a sequence of chat-completion deltas. Agent API streams use Responses-style event types and need terminal handling for completed, failed, incomplete and cancelled outcomes plus transport errors. If your current front end is tightly coupled to choices[0].delta.content, put a stream-normalisation layer in place before the migration. That work is useful even if you never change providers because it isolates UI rendering from protocol details.
Perplexity also claims meaningful benchmark improvements for the Agent presets relative to Sonar, including roughly seven times better BrowseComp performance for a low preset than Sonar Pro at about five cents per query. Treat vendor benchmark claims as directional rather than universal application guarantees. The decision to migrate does not need the benchmark to be true for your workload because the retirement date already forces the endpoint decision. Your own acceptance tests should measure answer quality, citation coverage, latency and cost on the queries your users actually send.
Build a Production Pattern That Survives the Switch
A migration-resistant implementation has five layers. First, a request builder owns model or preset selection, user input and search controls. Second, a provider client performs the network call. Third, a normaliser converts provider output into your own answer, sources, usage, status and error schema. Fourth, a policy layer decides when insufficient evidence should block display, when a retry is safe and when a cheaper route is acceptable. Fifth, telemetry records latency, cost, source count, status and route so you can compare Sonar and Agent traffic during the changeover.
That structure also supports a staged migration. Run the existing Sonar path as the control, send a small shadow sample through Agent API, compare normalised outputs offline, then increase Agent traffic after your quality thresholds are met. Avoid double-billing every production request for long periods. A short sampled comparison is usually enough to catch request-shape errors, missing search tools, citation parsing differences and unexpected cost movement.
For recurring jobs, our workflow automation with Perplexity guide provides a broader automation context. At API level, the crucial controls are idempotency where side effects exist, bounded concurrency, explicit timeouts, persistent job state for long research work and a dead-letter path for requests that fail after the retry budget.
I would also define acceptance checks around evidence rather than only exact wording. Search-grounded answers are non-deterministic because the web changes and ranking can shift. A stronger regression test asks whether the response contains required factual fields, whether at least one allowed-domain source is present, whether source dates satisfy freshness constraints, whether total cost stays below a feature budget and whether latency stays within the service-level objective. Exact-string snapshots are useful for schema testing but brittle for live research output.
The final design principle is to keep a competitor exit path. Sonar is convenient precisely because retrieval and synthesis are bundled, but that bundle also gives you less control over individual retrieval steps than raw-search architectures. If your product later needs custom reranking, proprietary retrieval, private corpora or a different reasoning model, your own provider-neutral answer-and-evidence schema will make that change far cheaper. Balanced architecture is more valuable than loyalty to any one AI endpoint.
What Most Sonar Tutorials Now Miss
The current search results are crowded with competent quick-starts, but several recurring omissions create an information gap. First, older guides present Sonar as a stable endpoint without a retirement plan. Second, some tutorials describe /chat/completions as though it were the canonical route, while Perplexity now documents /v1/sonar as canonical and the chat route as a compatibility alias. Third, many prompting explanations treat system and user messages as equivalent influences on search, despite Perplexity documenting that only the user message shapes Sonar retrieval.
Pricing is another weak spot. Some articles headline the $1 per million token rate and underplay or omit the per-request search-context fee. That can make a tiny, high-volume lookup product look cheaper on paper than it is. Another visible guide claims a 94% citation rate from ‘production testing’ without publishing a reproducible methodology or primary benchmark. I found no official Perplexity source that verifies that 94% figure, so this article does not repeat it as fact.
The migration contract adds three more details that are easy to miss: Agent API search needs an explicit tool or preset, Agent citations move into the output structure, and an Agent response can use HTTP 200 even when its application-level status is failed or cancelled. Those are not SEO-friendly feature bullets, but they are exactly the details that create production incidents when developers migrate by swapping a URL and assume the rest of the contract is identical.
The information-gain advantage is therefore practical rather than cosmetic: a working Sonar request, an explicit retrieval model, full current cost accounting, tier-aware capacity planning and a tested migration boundary. A page that covers those together answers the search intent a developer actually has in September 2026: not merely ‘how do I call Sonar?’, but ‘how do I call it correctly without rebuilding the integration later this month?’
Our Content Testing Methodology
This guide was treated as a troubleshooting and implementation workflow. I reviewed the current Perplexity developer quick-start, Sonar model cards, OpenAI compatibility guide, prompt guide, filters, pricing, rate-limit documentation, Pro Search behaviour, Agent API retirement announcement and the official Sonar-to-Agent migration skill. I then compared those primary-source contracts against ten currently discoverable 2026 Sonar and Perplexity API guides, including developer walkthroughs, Sonar tutorials, pricing analyses and web-search API comparisons, specifically looking for stale endpoints, unsupported benchmarks, missing fees and migration omissions.
I did not execute paid requests against a private Perplexity API account because no user-owned API key was supplied. The code in this article follows Perplexity’s documented SDK and request examples, and the cost calculations use published prices, but latency and answer-quality claims are not presented as personal live-traffic measurements. This distinction is deliberate: reproducible documentation evidence is stronger than pretending an unrun request was hands-on testing.
I also attempted the Perplexity AI Magazine sitemap locations specified in the editorial brief. The browsing layer did not return parseable sitemap XML, so I did not invent a sitemap inventory. The eight internal links were selected from live indexed Perplexity AI Magazine pages returned by search and limited to API architecture, keys, coding, accuracy, rate limits, 429 handling, agent building and workflow automation. Each appears once in a body section.
This article was researched and drafted with AI assistance and reviewed by the Sami Ullah Khan editorial desk at Perplexity AI Magazine. All data, citations, pricing figures, and named quotes have been independently verified against primary sources before publication.
Conclusion
Using Sonar in September 2026 is technically easy and strategically temporary. A developer can still create a key, call the Sonar chat-completions interface, retrieve a current answer with citations and control search through domains, dates, languages and search context. The larger engineering task is recognising that the endpoint sits inside a scheduled transition. Perplexity says Sonar tiers retire on 27 September 2026, so a new integration that stops at a successful first response is already incomplete.
The safest implementation keeps the current Sonar call behind a small provider boundary, logs citations and the returned cost object, treats user-message phrasing as a retrieval input, applies tier-aware backoff, and validates evidence rather than assuming every cited answer is correct. New applications should favour Agent API unless they have a concrete reason to remain on Sonar during the remaining window. Search API remains the better fit when a product wants ranked retrieval without Perplexity synthesising the answer.
Open questions remain around how real workloads compare after migration, especially latency, citation behaviour and cost under different Agent presets. Those should be measured on the application’s own query distribution. The endpoint decision, however, is no longer open-ended: Sonar works now, but production architecture should already be built for what comes next.
Frequently Asked Questions
Is the Perplexity Sonar API still available in September 2026?
Yes. Perplexity says Sonar endpoints remain available until 27 September 2026. It also says the Sonar tiers retire on that date and existing callers must point integrations to Agent API before retirement or the calls will stop working.
What is the current Perplexity Sonar API endpoint?
Perplexity documents POST /v1/sonar as the canonical Sonar endpoint. For OpenAI SDK compatibility, /chat/completions is also accepted as an alias, which lets existing chat-completions clients work after changing the base URL and API key.
Can I use the OpenAI Python SDK with Perplexity Sonar?
Yes. Perplexity supports the OpenAI Chat Completions request format for Sonar. Configure the client with a Perplexity API key and Perplexity base URL, then use a Sonar model. For new code, Perplexity recommends its own SDK for better type coverage.
Does the system prompt control what Sonar searches?
No. Perplexity’s Sonar prompt guide says search happens before generation and only the user message drives retrieval. Use the system message for answer style and grounding rules, and use request parameters for domain, date, language and context constraints.
How much does the Sonar API cost?
Standard Sonar is listed at $1 per million input tokens and $1 per million output tokens, plus a request fee of $5, $8 or $12 per 1,000 requests for low, medium or high search context. Other Sonar models have different token and request rates.
What is the Sonar API rate limit?
It depends on cumulative API credits purchased. Sonar, Sonar Pro and Sonar Reasoning Pro range from 50 RPM at Tier 0 to 4,000 RPM at Tiers 4 and 5. Deep Research ranges from 5 RPM to 100 RPM.
Should a new application use Sonar or Agent API?
Perplexity recommends Agent API for new applications, especially because Sonar tiers retire on 27 September 2026. Use Sonar only when maintaining or finishing a short-lived existing Sonar integration, and design the provider boundary for migration.
When should I use Perplexity Search API instead of Sonar?
Use Search API when you need raw ranked web results for your own RAG, reranking or synthesis pipeline. Use Sonar when you want Perplexity to return a synthesised answer with citations in the same request.
References
Perplexity AI. (2026). Quickstart: Perplexity API.
Perplexity AI. (2026). OpenAI SDK compatibility for Sonar.
Perplexity AI. (2026). Sonar prompt guide.
Perplexity AI. (2026). API pricing.
Perplexity AI. (2026). Rate limits and usage tiers.
Perplexity AI. (2026). Agent API: Build with LLMs, the Web, and Agents.
Perplexity AI. (2026). Migrate Sonar to Agent API.
Katanenko, M. (2026, June 15). Perplexity MCP: Connecting Perplexity to your tools.
Zeeb, N. (2026, June 30). Best web search APIs and MCPs for AI agents in 2026.
