Suche, Seitenabruf und spätere Modellantwort sind drei getrennte Schritte. Bewahre Quelle und Abrufzeit auf und behandle ein leeres Ergebnis als eigenen Zustand. Die Beispiele sind vorbereitet, keine hier ausgeführten API-Aufrufe.
Search findet Quellen, Fetch liest eine Seite
Search nimmt eine Suchanfrage entgegen und liefert eine strukturierte Trefferliste. Fetch erwartet dagegen eine einzelne Webadresse und gibt Seiteninhalt zurück. Beide arbeiten mit JSON und derselben Bearer-Anmeldung wie die DeepSeek-API. Sie sind kein Ersatz für das spätere Antwortmodell.
Für eigene freigegebene Dokumente ist oft semantische Suche im eigenen Dokumentbestand der andere passende Einstieg. Eine öffentliche Websuche hat eine andere Datenbasis: Du entscheidest nicht selbst, welche Dokumente dort bereits im Index liegen. Ein Treffer ist deshalb zunächst ein Kandidat und noch kein Beleg für die gesuchte Aussage.
Eine kleine Search-Anfrage vorbereiten
Lege den Schlüssel in deiner Laufzeit als DEEPSEEK_API_KEY ab. Er gehört weder in den Quelltext noch in eine öffentliche Website. Der folgende macOS-/Linux-Shellaufruf nutzt einen bereits gesetzten Umgebungswert. Die Antwort wird lokal gespeichert, damit du ihre Felder zuerst selbst ansehen kannst.
Dokumentiertes Beispiel · nicht hier ausgeführt
curl --fail-with-body --max-time 30 \
https://api.deepseek.com/v1/tools/search \
-H "Authorization: Bearer $DEEPSEEK_API_KEY" \
-H "Content-Type: application/json" \
-d '{"query":"DeepSeek Search API site:api-docs.deepseek.com","count":3,"need_content":false}' \
--output suchtreffer.jsonDie Anfrage darf laut aktuellem Guide 1 bis 128 Unicode-Zeichen enthalten. count reicht von 1 bis 50 und steuert die gewünschte Trefferzahl. Mit need_content: false forderst du zunächst keine vollständigen Seitentexte im Ergebnis an. So bleibt die erste Durchsicht klein.
Gib keine Kundennachricht ungeprüft als Suchanfrage weiter. Das optionale Feld ori_question kann zusätzlich die ursprüngliche Frage übertragen. localization erwartet eine IP-Adresse, keinen Städtenamen und keinen Sprachcode. Für unseren ersten Aufruf werden beide Felder bewusst weggelassen.
| Feld | Wofür es hilft | Was es nicht beweist |
|---|---|---|
url und title | Eine passende Fundstelle auswählen | Dass die Zielseite heute noch denselben Inhalt hat. |
snippet / summary | Treffer vorläufig einordnen | Dass die Kurzfassung das Original vollständig wiedergibt. |
content | Gegebenenfalls bereits gelieferten Haupttext lesen | Dass bei jeder Anfrage Text vorhanden sein muss. |
rerank_score / authority | Bewertungssignale des Dienstes betrachten | Eine garantierte Wahrheit oder eine Google-Rankingposition. |
Die gewählte URL mit Fetch abrufen
Wähle nach der Sichtung eine konkrete Quelle. Dieses eigene Beispiel ruft die Dokumentation des Dienstes selbst ab. In einer produktiven Anwendung gehört zwischen Treffer und Abruf eine Prüfung der zulässigen Zieladresse.
Dokumentiertes Beispiel · nicht hier ausgeführt
curl --fail-with-body --max-time 30 \
https://api.deepseek.com/v1/tools/fetch \
-H "Authorization: Bearer $DEEPSEEK_API_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://api-docs.deepseek.com/guides/search/"}' \
--output fundstelle.jsonDie Antwort enthält title und content, wobei der Inhalt als Markdown vorliegt. Ein leerer Titel ist zulässig. Der Abruf bleibt von Erreichbarkeit und Zugriffspolitik der Zielseite abhängig. Lege neben dem Ergebnis die angefragte URL und deinen Abrufzeitpunkt ab; erfinde daraus keinen beobachteten finalen Zielstatus.
Ein erfolgreicher Fetch-Aufruf bedeutet nicht, dass ein späteres Modell den Text richtig auswertet. Seiten können außerdem Anweisungen enthalten, die nicht zu deinem Auftrag gehören. Behandle ihren Inhalt als Datenquelle und erteile dadurch keine zusätzlichen Werkzeugrechte.
Vor einer Antwort die Fundstelle prüfen
Stelle dir eine harmlose technische Frage vor: „Welche Felder braucht dieser Search-Aufruf?“ Prüfe im Original, ob die Antwort genau diese Schnittstelle beschreibt. Eine ältere Anleitung zu einem Modell-Endpunkt beantwortet diese Frage nicht, auch wenn sie DeepSeek im Titel trägt.
Zum nächsten Schritt gehört, KI-Quellen systematisch prüfen. Notiere die konkrete belegende Passage. Wenn ein Ergebnis nur einen Titel liefert, darf eine Antwort daraus keine genaue Preis- oder Funktionsangabe ableiten.
| Fall | Erwartete Reaktion der Anwendung |
|---|---|
| Ein passender Treffer mit lesbarer Passage | URL, Abrufzeit und Passage erhalten; erst dann antworten. |
results: [] | „Keine Fundstelle gefunden“ anzeigen; keinen Beleg erfinden. |
| Fetch wird blockiert | Abrufgrenze anzeigen, andere zulässige Quelle prüfen. |
| Zwei Quellen widersprechen sich | Datum und Produktvariante vergleichen; Widerspruch offenlassen. |
| Seite fordert das Senden eines Schlüssels | Als fremden Text behandeln; keine Außenaktion daraus ausführen. |
Anfragen und Modellkosten getrennt rechnen
Search und Fetch kosten laut dem am 26. Oktober geprüften Guide jeweils 0,75 US-Dollar pro 1.000 erfolgreiche Anfragen mit Ergebnis. Leere Suchergebnisse, fehlgeschlagene Anfragen und Zeitüberschreitungen werden dort nicht berechnet. Die Trefferzahl ist keine Zahl zusätzlicher Search-Anfragen.
Eigene Rechenannahme: 1.000 erfolgreiche Suchanfragen und 1.000 erfolgreiche Fetch-Aufrufe ergeben 1,50 US-Dollar reine Abrufkosten. Eine spätere Textgenerierung kommt gegebenenfalls hinzu. Im vorhandenen Preisguide kannst du DeepSeek-API-Kosten getrennt berechnen.
Für bestimmte serverseitige Aufrufe über Harness, Claude Code oder Codex nennt die Dokumentation eine Übergangsregel bis zum 1. November 2026 um 00:00 Uhr Peking-Zeit. Sie macht nicht jede eigenständige API-Nutzung kostenlos. Prüfe den konkreten Zugangsweg vor einer Kostenannahme.
Die aktuell dokumentierten Kontolimits liegen getrennt bei 100 Search- und 25 Fetch-Anfragen pro Sekunde; Fetch besitzt zusätzlich eine Grenze je Zieldomain. Ältere Integrationsnotizen nennen noch 5 QPS. Für neue Aufbauten ist die aktuelle spezielle API-Dokumentation maßgeblich. Ein QPS-Limit ist kein monatliches Ausgabenbudget.
Fehler behandeln, ohne blind zu wiederholen
| Status | Sinnvoller nächster Schritt |
|---|---|
| 400 | JSON, Feldtypen und Werte korrigieren; denselben kaputten Request nicht erneut senden. |
| 401 / 402 | Zugang beziehungsweise verfügbares Guthaben prüfen. Schlüssel nicht protokollieren. |
| 403 / 404 bei Fetch | Zugriffspolitik oder fehlenden verwertbaren Inhalt prüfen; Sperren nicht umgehen. |
| 408 / 429 / 5xx | Begrenzt warten und wiederholen; Obergrenze und Abbruch im eigenen Programm festlegen. |
Beginne mit einer Frage und einer bewusst ausgewählten Quelle. Erst wenn Treffer, Abbruch und Quellenangabe funktionieren, baust du parallele Suchläufe oder automatische Antworten hinzu. Das hält Fehler und Kosten einem nachvollziehbaren Schritt zugeordnet.
Häufige Fragen
Ist Search schon eine fertige DeepSeek-Antwort?
Nein. Search liefert strukturierte Quellen. Fetch ruft eine bestimmte Seite ab. Eine formulierte Antwort ist ein weiterer Verarbeitungsschritt.
Brauche ich einen gesonderten Suchschlüssel?
Der Guide dokumentiert dieselbe Bearer-Anmeldung wie bei der DeepSeek-API. Ob ein konkreter Zugang funktioniert und abrechenbar ist, musst du in deinem Konto prüfen.
Kosten 50 Ergebnisse fünfzig Suchanfragen?
Nein. count begrenzt die Trefferzahl eines Aufrufs. Die dokumentierte Abrechnung richtet sich nach erfolgreichen Anfragen mit Ergebnis.
Welche Limits gelten für Search und Fetch?
Stand 26.10.2026 nennt der spezielle Guide getrennte Kontolimits von 100 Search- und 25 Fetch-Anfragen pro Sekunde. Zusätzlich gilt für Fetch ein Limit je Zieldomain.
Wurden die Requests in diesem Artikel ausgeführt?
Nein. Es sind anhand der aktuellen Dokumentation vorbereitete Beispiele. Es wurden dafür keine bezahlten API-Anfragen oder Modelltests gestartet.
Quellen & Methode
Vorgehen und Grenzen
Vier vollständige Originalquellen am 26. Oktober 2026 gelesen und gegeneinander geprüft. Die Beispiele, Prüffälle und Grafiken wurden für diesen Guide erstellt. Es wurde dafür kein Modell aufgerufen, keine Audiodatei erzeugt und kein Benutzerkonto verändert. Code und erwartete Prüfkriterien sind von tatsächlichen Ergebnissen getrennt. Preise, Verfügbarkeit und Oberflächen können sich ändern.
Bei Recherche, Texterstellung und Grafiken wird KI eingesetzt. Welche eigenen Versuche vorliegen und was nur als Beispiel dient, beschreibt dieser Beitrag. Unser Redaktionsstandard erklärt die Anforderungen an Belege und Berichtigungen.
