The new endpoints split discovery from reading
DeepSeek's Search API accepts a query and returns up to 50 structured results. Each result can include a title, URL, short snippet, longer model-facing summary, page content, publication date, a rerank score, and an authority tier. The separate Fetch API accepts one URL and returns a title plus extracted Markdown.[1]
That split is useful. An agent can search broadly, choose a URL, then fetch only the page it needs. Search and Fetch each have an account-level limit of five requests per second. Fetch also has a per-domain limit. The documentation says the target site's availability and access policies still govern whether a page can be retrieved.[1]
Ranking chooses what to inspect. It does not decide what is true.
An authority tier is provider metadata
DeepSeek describes authority as a tier from zero to four, with minus one for unknown. It describes three or above as highly authoritative. The docs do not publish a complete method for assigning that tier. Record it as the provider's score, not as a fact about the page.
The same rule applies to rerank_score. DeepSeek says the zero-to-three value combines relevance, authority, and freshness. A high score can help order a queue. It cannot show that a page supports a specific sentence, that the page is current, or that the author is qualified to make the claim.
Fetched Markdown is a representation
Fetch returns extracted Markdown, not a browser session or a signed copy of the source. Extraction can omit scripts, diagrams, footnotes, tables, update banners, or text hidden behind an interaction. A successful response proves that the service returned content for the URL at that time. It does not prove that every important part of the page survived extraction.
Keep the URL beside the fetched text. Open the original page for claims that carry dates, numbers, safety consequences, release status, or attribution. If the live page and extraction disagree, preserve both and stop the claim until the mismatch is explained.
The price rewards batching, not skipping review
Search and Fetch are each billed at $0.75 per 1,000 successful requests. A Search request is billable only when HTTP 200 includes a nonempty result array. A Fetch request is billable only when HTTP 200 includes page content. Result count does not change the per-request price.[1]
That means one search plus three fetches costs four successful-request units. The cheap move is to search once, rank the candidates, and fetch the small set that could support the claim. The reckless move is to accept the first model-facing summary because retrieval is now fast.
Make the claim carry its route
QUERY="exact release name site:official-domain.example"
SEARCH_TIME=[UTC TIMESTAMP]
RESULT_URL=[EXACT URL]
PROVIDER_RERANK_SCORE=[RECORDED, NOT A VERDICT]
PROVIDER_AUTHORITY_TIER=[RECORDED, NOT A VERDICT]
FETCH_STATUS=[HTTP STATUS]
SOURCE_AUTHOR=[REQUIRED]
SOURCE_DATE=[REQUIRED OR UNKNOWN]
CLAIM=[ONE SENTENCE]
SUPPORT=[EXACT QUOTE OR SECTION]
LIMIT=[WHAT THIS SOURCE DOES NOT ESTABLISH]Keep one claim per record. A product guide can document an endpoint. It cannot prove independent reliability. A release post can establish what a publisher announced. It cannot establish performance on your workload. A discussion can expose questions worth testing. It cannot replace the product source.