DeepSeek's application APIs explained: web search, files and links in one call, and what an answer costs

DeepSeek's chat app has done more than call a model for a long time. It searches the web, reads the links you paste, answers from files you upload, reads answers aloud and checks content for safety. On 13 November 2026 DeepSeek opened all of that to developers. Its news post says you can "recreate the full DeepSeek App in your own application".

There are two parts. The first is a set of switches on the normal chat request: web search, deep thinking search, file input, URL reading and a safety check, plus two smaller ones, a conversation title and a "user metadata marker" that tells the model today's date and the user's location and language. The second is a set of standalone APIs for the same pieces: Search, Fetch, OCR (reading text from images and scans), speech to text and text to speech.

DeepSeek also published a full chat app built on these APIs, as open source under the MIT licence, at github.com/deepseek-ai/chat-demo. You enter your own API key, and your key, chats and images stay in your browser. It can import the chat history you exported from DeepSeek Chat.

DeepSeek lists these switches for the deepseek-flash model only (DeepSeek-V4.1-Flash-1017 on the pricing page) and does not mention deepseek-v4-pro. This page covers how the switches work, what an answer costs, and the two places where a team moving its chatbot onto them is most likely to get it wrong.

You add tools to an ordinary request: {"type": "deepseek_web_search"} and {"type": "deepseek_read_url"}. These are server tools. The model decides whether it needs to go online, DeepSeek's servers run the search or fetch the page, and the results go into the model's context before it writes the answer. Your code never executes a tool call, which is the difference from normal function calling, where your app runs the tool and sends the result back.

With thinking turned off, deepseek_web_search does a plain web search and the answer comes with citations. With thinking turned on, it becomes deep thinking search: over several reasoning steps the model searches, opens pages and looks for text inside them, up to about 20 tool calls before it answers, DeepSeek says. URL reading works on the links in the user's latest message: the model considers up to the first 10 different ones and chooses which to read. With thinking on and web search declared, links are not read separately; deep thinking search handles the round.

What comes back is a list of typed blocks, in the same shape as Anthropic's Messages API: thinking, a server_tool_use block for each call, a web_search_tool_result or web_fetch_tool_result block for each result, and text blocks with citations. Your app shows them: a search step with result cards, a page that was opened, the answer with citation markers.

Two smaller rules matter in practice. When a request declares deepseek_web_search or deepseek_read_url, sets safety_check to high, or turns on the conversation title, DeepSeek sets some parameters itself and ignores yours: temperature and top_p in all three formats, and others such as stop sequences in Messages and seed in Chat Completions. And max_tokens limits the output of each step, not the whole answer, so max_tokens alone does not limit the total output, or the cost, of one answer.

Read next: The tool-calling contract: who runs the tool and who checks the result

Setting safety_check to {"level": "high"} turns on what DeepSeek calls basic risk control: the input and the output are both reviewed. The input includes user messages, tool results and pages read from links. A blocked input usually returns an HTTP 400 error, "Content Exists Risk"; a blocked image ends the reply with a refusal that names it instead. A page read from a link that fails the review comes back as a url_not_allowed error instead of its content, and that fetch is still billed.

The part to design for is the output. With the check on, the connection stays open after the model writes its last word while DeepSeek reviews the whole answer, and the reply can still end in a refusal. By then your user may have watched the full answer stream in. DeepSeek's guide says text that has already been streamed cannot be withdrawn, and tells you to remove the displayed answer and show your own refusal message. A chat screen that only appends text has no way to do that, so it needs a path that replaces a finished answer.

DeepSeek says a public-facing app must turn this check on, and that it does not replace the provider's own duties: content review, large-model registration and labelling AI-generated content. These match China's rules for public generative AI services, which is my reading, not DeepSeek's wording. If you serve users elsewhere, read the check as a first layer, and keep your own guardrails and your own review of what the model says.

Read next: LLM guardrails and safety: what to check before and after the model

The facts come from DeepSeek's news post of 13 November 2026 and from its Build a Chatbot, Web Tools, Model Content Safety, File Parsing and Search & Fetch guides and its Models & Pricing page, all read on 15 November 2026 and linked below. The meaning of web_search_requests on Anthropic's API and the $10 per 1,000 price come from Anthropic's web search tool docs, read the same day.

I did not call DeepSeek's API, because we have no DeepSeek key, so I cannot confirm the answer quality, the speed or the safety check's behaviour myself. The costs are my arithmetic on DeepSeek's own example responses and list prices. The pass-back test runs DeepSeek's real demo code on a history I wrote; it shows what that client sends, not what the server does with it, which is DeepSeek's description.