← Back to notes
TESTED API WALKTHROUGH / 18 OCTOBER 2026

DeepSeek Search & Fetch API:
what our requests returned.

We sent a search query, fetched two public pages, and deliberately used an invalid result count. Here are the requests, the responses we checked, and a date-field trap that matters when you use search results in an agent.

Tested October 18, 2026, with Python’s standard-library urllib client and an existing DeepSeek API account. Four requests, one account, one short session. This is a functional walkthrough, not a speed benchmark or a comparison with another search provider.

What we actually tested

Our task was to find the current US daylight-saving rules and retrieve the source text. We used a narrow query on NIST’s site so that we could check the result against a named source rather than judge an answer by how plausible it sounded.

RequestObserved result
Search: site:nist.gov daylight saving time 2026, count 3, need_content falseHTTP 200; three results. Each content field was empty, while titles, URLs and summaries were present.
Fetch: example.comHTTP 200; title and non-empty content. A simple check of the response shape.
Fetch: NIST’s Daylight Saving Time Rules pageHTTP 200; title and Markdown text containing the 2026 rule.
Search: same query with count 0HTTP 400; invalid_request_error, with a message saying count must be between 1 and 50.

Search results can change. The three results above describe this run, not a guaranteed future response. We did not test every query operator, rate limiting, retries under load or billing totals.

Search and Fetch do different jobs

Search finds candidate pages. POST /v1/tools/search returns a results array. In our run, need_content: false left each result’s content empty; the separate summary field still contained text.

Fetch retrieves one selected page. POST /v1/tools/fetch returned title and content for the URL we supplied. These are tool endpoints, not model names for a chat-completions request. Use the official Search & Fetch guide for the full schema.

Run the Python example

Set DEEPSEEK_API_KEY in your local environment, then run the code below with Python 3. It uses no third-party Python package. The key is read from your environment and sent to DeepSeek; this page has no key input and makes no API requests from your browser.

The example prints the search candidates before selecting a URL on www.nist.gov. If that host is absent from your results, review the returned URLs and choose the appropriate source instead of blindly fetching the first hit.

import json
import os
from urllib.request import Request, urlopen
from urllib.error import HTTPError

API_KEY = os.environ["DEEPSEEK_API_KEY"]
BASE_URL = "https://api.deepseek.com/v1/tools/"

def post(tool, payload):
    request = Request(
        BASE_URL + tool,
        data=json.dumps(payload).encode("utf-8"),
        headers={
            "Authorization": "Bearer " + API_KEY,
            "Content-Type": "application/json",
        },
        method="POST",
    )
    try:
        with urlopen(request, timeout=30) as response:
            return json.load(response)
    except HTTPError as error:
        # Read the error body; do not print your authorization header.
        print("HTTP", error.code, error.read().decode("utf-8"))
        raise

search = post("search", {
    "query": "site:nist.gov daylight saving time 2026",
    "count": 3,
    "need_content": False,
})

for result in search["results"]:
    print(result["title"], result["url"], result.get("date"))

# Review the returned URLs before fetching one.
candidate = next(
    result for result in search["results"]
    if result["url"].startswith("https://www.nist.gov/")
)
page = post("fetch", {"url": candidate["url"]})
print(page["title"])
print(page["content"][:500])

The request shape follows the same fields we used in the live checks. A missing local environment variable will stop the script before it sends a request.

The date field did not tell the whole freshness story

The first search result pointed to NIST’s current rules page. Its result-level date was in 2010. The fetched page, however, contained the 2026 rule and a February 2026 update note. The result date and the page’s latest update were different signals.

The other two results were historical PDFs. Restricting a query to a reliable domain helped us find an authoritative source, but it did not make every returned document current or relevant to the 2026 question.

  1. Inspect the title and URL before choosing a result.
  2. Fetch the source you intend to use.
  3. Check the year and update note in the page text.
  4. Keep old law, historical descriptions and current rules separate in your answer.

For the date question itself, our 2026 US–UK clock-change guide links the current sources and includes a meeting-time checker. This API test illustrates retrieval; it does not replace checking the source.

The count error we reproduced

Changing count from 3 to 0 produced HTTP 400. The response used an error object, with type and code set to invalid_request_error. The message identified the allowed range, 1 to 50.

We corrected the request field rather than retrying the same invalid request. When troubleshooting your own call, keep the HTTP status and error body; do not share an authorization header or API key in a bug report.

Billing and scope to check before using it

At the time we checked the official guide, direct Search and Fetch calls were listed at $0.75 per 1,000 successful requests each. The guide says the result count does not change the per-request price. Integrated server-side tools had a temporary exemption, with billing stated to begin at 00:00 Beijing time on November 1, 2026. Check the current terms for your calling route.

Our direct JSON requests used the regular tool endpoints. We did not test an integrated agent’s billing behavior or compare retrieval quality across providers. To inspect a saved response locally, use the JSON formatter.