Jede 1.000 erfolgreich beantwortete Anfrage an die Search API von DeepSeek kostet 0,75 US-Dollar. Das sind Bruchteile eines Cents pro Suche, egal wie viele Treffer am Ende zurückkommen. Neben der Suche gibt es eine zweite, kleinere Schnittstelle: die Fetch API. Sie ruft eine einzelne Webseite ab und gibt deren Inhalt als Markdown zurück. Beide Dienste sind rohe JSON-APIs, teilen sich denselben Schlüssel wie das Sprachmodell und laufen über die Basis-URL https://api.deepseek.com.
Für RAG-Anwendungen schließen die Dienste die Lücke zwischen Trainingswissen und dem aktuellen Stand des Netzes. Wer ein Retrieval-System baut, braucht Embeddings über eigene Dokumente und oft auch frische Quellen von außen. DeepSeek liefert dafür zwei getrennte Werkzeuge: eines, das findet, und eines, das holt. Man kann sich das wie eine Bibliothek mit Zettelkatalog vorstellen.
Zwei Dienste, ein Konto: Search und Fetch unter derselben Basis-URL
Die Search API ist der Bibliothekar, der durch die Regale läuft, Karteikarten zieht und sortiert zurücklegt. Die Fetch API ist der Bote, den man mit einer Signatur losschickt, damit er genau ein Buch holt und abtippt. Beide sprechen über POST https://api.deepseek.com/v1/tools/search beziehungsweise POST https://api.deepseek.com/v1/tools/fetch, und beide verlangen dieselbe Authentifizierung wie der Rest der DeepSeek API.
Die Authentifizierung läuft über einen Bearer Token im HTTP-Header: Authorization: Bearer <DeepSeek API Key>. Dazu kommt Content-Type: application/json, weil beide Endpunkte ausschließlich JSON im Body annehmen. Wer schon einen Schlüssel für Chat-Anfragen besitzt, braucht keinen neuen; die Doku der Search API und der Fetch API verweist auf dieselbe Schlüsselverwaltung. Der Schlüssel gehört nie ins Frontend, sondern bleibt serverseitig und wird dort pro Anfrage gesetzt.
Wie die Search API aus einer Anfrage eine strukturierte Trefferliste macht
Der Kern einer Suchanfrage ist das Feld query: ein bis 128 Unicode-Zeichen, kein reiner Leerraum. Dazu kommen vier optionale Felder, die man in der DeepSeek Search API Dokumentation leicht überliest, die aber die Qualität beeinflussen. count steuert, wie viele Treffer zurückkommen – erlaubt sind 1 bis 50, voreingestellt sind 10. ori_question nimmt die ursprüngliche Nutzerfrage auf, ebenfalls 1 bis 128 Zeichen, damit die Suche den Kontext besser versteht; ein null gilt als nicht gesetzt.
localization erwartet eine optionale IP-Adresse, um Ergebnisse regional zu gewichten. Das hilft, wenn die Frage nach lokalen Angeboten, Öffnungszeiten oder regionalen Nachrichten verlangt und nicht nach einer allgemeinen Definition. Mit need_content schließlich lässt sich anfordern, dass jeder Treffer schon den Seiteninhalt im Feld content mitbringt; ohne diesen Schalter bleibt content eine leere Zeichenkette. Unbekannte Felder im Request-Body werden ignoriert. Das macht die Integration robust, heißt aber auch, dass ein Tippfehler im Feldnamen stillschweigend verschluckt wird.
Suchoperatoren: site, lang, after und before
Die Anfrage wird samt Suchsyntax unverändert an die Suchmaschine weitergegeben. Wer die Operatoren beherrscht, bekommt deutlich genauere Treffer als mit reinen Stichwörtern. Der Operator site: beschränkt die Ergebnisse auf eine Domain, etwa DeepSeek site:github.com. Mehrere Ziele lassen sich mit OR verbinden, also DeepSeek site:github.com OR site:huggingface.co. Der Gegenteil-Fall ist -site:example.com, um eine Domain auszuschließen.
Für RAG-Anwendungen besonders nützlich ist der Zeitfilter. after:2025 oder präziser after:2025-01-01 beschränkt auf Seiten, die nach dem Datum veröffentlicht wurden, before:2026 entsprechend auf ältere Inhalte. So lässt sich verhindern, dass ein Modell mit veralteten Artikeln gefüttert wird. Dazu kommen lang:zh,en für die Sprachbeschränkung, -advertisement zum Ausschluss einzelner Begriffe und die Anführungszeichen für exakte Phrasen, also "release notes" oder ausgeschlossen -"release notes". Mehrere Operatoren lassen sich in einer Query kombinieren. Damit werden Treffer gezielt eingegrenzt statt nur Stichwörter geraten.
Was in einem Treffer steckt: von snippet bis rerank_score
Eine erfolgreiche Suche liefert HTTP 200 mit einem Feld results. Findet sich nichts, ist das Array leer – ein normaler Fall, kein Fehler. Jeder Treffer enthält mehrere textuelle Ebenen für unterschiedliche Adressaten. snippet ist ein kurzer Auszug von etwa 100 bis 200 Zeichen, gedacht für die Anzeige in einer Oberfläche. summary ist mit typisch 600 bis 800 Zeichen die längere Zusammenfassung, ausdrücklich für das Modell, das sie lesen soll.
Sortiert wird über rerank_score, einen Wert zwischen 0 und 3, der Relevanz, Autorität und Frische bündelt. Ab 1,5 gilt ein Ergebnis als hochwertig. Unabhängig davon gibt es authority, eine Autoritätsstufe von 0 bis 4, wobei 3 und höher für besonders verlässliche Quellen stehen und -1 für unbekannt. Ergänzt wird das durch site_name, site_icon und date im RFC-3339-Format in UTC, jeweils null, wenn die Angabe fehlt. Wer eine Quellenbewertung bauen will, hat hier zwei unabhängige Signale, ohne selbst nachrechnen zu müssen.
Die Fetch API holt eine Seite als Markdown
Der zweite Endpunkt ist bewusst schlicht: Man übergibt eine url und bekommt title und content zurück. Der Inhalt kommt als Markdown, was ihn für Sprachmodelle deutlich besser verdaulich macht als rohes HTML mit Navigationsleisten, Cookie-Bannern und Inline-Styles. Der Punkt ist: Die Fetch API liefert eine Webseite als Markdown – nicht als Screenshot, nicht als DOM-Baum.
Die Anforderungen an die URL sind klar umrissen: maximal 8192 Zeichen, ein HTTP- oder HTTPS-Schema mit Host, und keine Zugangsdaten im URL-String. Der Abruf unterliegt der Verfügbarkeit und den Zugriffsregeln der Zielseite; die API ist ausdrücklich read-only und umgeht keine Paywalls oder Sperren. In der Praxis heißt das: Manche Seiten liefern verwertbaren Text, andere antworten mit einem Fehler. Ein System, das Fetch produktiv nutzt, braucht einen sauberen Umgang mit fehlenden Inhalten statt der Annahme, dass jeder Link funktioniert.
Fehlercodes, QPS-Grenzen und was am Ende abgerechnet wird
Fehler folgen dem OpenAI-kompatiblen Format mit message, type, code und einem param-Feld, das immer null ist. Die Statuscodes sagen ziemlich genau, was zu tun ist. 401 bedeutet fehlender oder ungültiger Schlüssel, 402 ein zu geringes Guthaben, 403 eine Ablehnung durch die Sicherheitsrichtlinie beim Fetch. 404 steht beim Abruf für nicht verwertbaren Seiteninhalt – etwa eine nicht erreichbare URL, eine gesperrte Seite, einen Fehler der Zielseite oder einen Inhaltstyp, aus dem sich kein Markdown extrahieren lässt.
Bei 408, 429 und allen 5xx-Fehlern ist Warten und erneutes Versuchen richtig; bei 402 muss zuerst das Konto aufgeladen werden. Andere 4xx-Fehler ohne Änderung der Anfrage zu wiederholen, bringt nichts. Die Ratenlimits liegen kontobasiert bei 100 Anfragen pro Sekunde für die Suche und 25 für Fetch, unabhängig davon, welcher API-Schlüssel verwendet wird. Beide Kontingente sind getrennt; Fetch unterliegt zusätzlich einem Limit pro Domain. Überschreitungen führen zu HTTP 429.
Abgerechnet wird pro erfolgreicher Anfrage, nicht pro Token und nicht nach Trefferzahl: 0,75 Dollar je 1.000 Requests, für beide Endpunkte gleich. Kostenpflichtig ist nur, was HTTP 200 liefert und ein Ergebnis produziert – die Suche also ein nicht-leeres results-Array, Fetch einen Seiteninhalt. Fehlversuche, leere Trefferlisten und Timeouts fallen nicht ins Gewicht. Ein höherer count ändert den Preis nicht, was die Kalkulation planbar macht. Wer die APIs über DeepSeek Harness, Claude Code oder Codex nutzt, löst serverseitige Tool-Aufrufe aus, die derzeit kostenfrei sind; die Abrechnung pro Anfrage beginnt dort am 1. November 2026 um 00:00 Uhr Pekinger Zeit.
Das sind zwei kleine, klar umrissene Werkzeuge für Live-Webinhalte in RAG-Anwendungen. Eigenes Crawling und Redaktionslogik ersetzen sie nicht, aber sie nehmen einem die Arbeit ab, aus einer Frage eine Trefferliste und aus einer URL lesbaren Text zu machen. Wer die Operatoren beherrscht, die Qualitätssignale im Response auswertet und Fehlercodes sauber behandelt, hat einen verlässlichen Zugang zu Webinhalten – zu einem Preis, der pro Anfrage feststeht.
Quelle: api-docs.deepseek.com
