DeepSeek Web Search API: Setup, Billing and Cost-Control Traps

DeepSeek opened its application capabilities through the API on November 13, including managed web search and URL reading. Developers can now let deepseek-flash retrieve information during an answer without implementing the search loop themselves. The important integration question is which controls still work once the service takes over that loop.

This is different from calling the existing standalone Search and Fetch endpoints. The new application API release brings those capabilities into model conversations, alongside file input, safety checks and speech APIs. It is not a new model release.

Start with a managed search request

The chatbot integration guide supports Responses, Messages and Chat Completions. Here is a documentation-based Responses example, not a request I have executed:

curl https://api.deepseek.com/responses \
  -H "Authorization: Bearer ${DEEPSEEK_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-flash",
    "reasoning": {"effort": "high"},
    "tools": [{"type": "deepseek_web_search"}],
    "safety_check": {"level": "high"},
    "input": "Check the official release notes for this week. Separate shipped changes from previews and cite each source.",
    "stream": true
  }'

Replace the deliberately broad example question with the product and dates you actually want checked. For an evaluation, choose release notes you have already read and keep a small answer key. Count unsupported claims and missed preview labels, not just whether the response looks well sourced.

According to the web-tools documentation, enabling thinking turns search into a multistep research process. For reading supplied links without search, declare only deepseek_read_url. The model still chooses whether to use a tool; naming a managed tool in tool_choice produces an error rather than forcing execution.

That makes the standalone endpoints preferable when your application must fetch a particular source before answering. A prompt asking for official sources is an instruction to the model, not an enforceable domain policy.

Budget a conversation, not one completion

The chatbot guide says max_output_tokens applies to each inference step, not the entire round. It also lists max_tool_calls among ignored Responses parameters for this application mode. Neither setting should be treated as your total research budget.

The published prices charge $0.75 per 1,000 searches and the same for fetches, separately from model tokens. The tool documentation says a successful search containing several queries is billed by query. Use tool_search, tool_fetch and tool_image_search in final usage, not the display-oriented request counters.

For example, four billed queries plus three fetches cost $0.00525, excluding tokens. This is illustrative arithmetic, not measured usage or a typical-request estimate.

A sensible rollout is to record whole-round usage before making this a default feature. Compare a simple fact lookup with a research task that needs several sources. Cheap individual searches can still be attached to a conversation whose inference cost and latency vary substantially.

Check completion and preserve conversation state

An HTTP 200 does not guarantee a finished answer. The web-tools guide documents generation failures inside successful HTTP responses, including response.failed during Responses streaming. Your UI should distinguish completed answers from interrupted ones rather than displaying partial text as a finished report.

Pass previous output items back unchanged, including DeepSeek's kind and signature fields. These preserve pages opened through deepseek_read_url; search results and pages opened during deep thinking search are not restored in later context, beyond the answer text. A client saving only visible text loses even the supported page state.

For a small acceptance test, read one supplied URL, follow up about a detail from that page, and deliberately interrupt another request. Inspect the saved state and the final status in each case. This is a proposed test, not a claim that the integration has passed it.

The useful tradeoff is clear: managed search reduces orchestration work, but it also moves decisions out of your code. Use it where flexible research is valuable. Keep deterministic retrieval outside the model when source selection is a requirement you need to prove.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn API changes and engineering decisions into clear stories developers can use.

Book a 30-minute call