Changelog

Ein öffentliches Protokoll der API-Änderungen. Additive, rückwärtskompatible Änderungen (neue optionale Felder); brechende Änderungen werden explizit markiert — bestehende Integrationen funktionieren unverändert weiter.

2026-07-28 — Umbenennung in ChunkChef

Das Produkt heißt jetzt ChunkChef. Drei Änderungen sind nach außen sichtbar, der Rest ist intern.

  • Breaking — Webhook-Signatur-Header umbenannt. X-Hotdoc-Timestamp und X-Hotdoc-Signature heißen nun X-Chunkchef-Timestamp und X-Chunkchef-Signature. Das Signaturverfahren bleibt unverändert; nur die Header-Namen ändern sich. Bitte passen Sie Ihre Prüfung an.
  • Breaking — Präfix des API-Schlüssels geändert. Neue Schlüssel werden als chunkchef_<id>.<secret> statt hotdoc_<id>.<secret> ausgestellt. Bestehende Schlüssel authentifizieren nicht mehr; erstellen Sie einen neuen im Dashboard.
  • Breaking — Diskriminator für typisierte Fehler geändert. In Status.details lautet @type jetzt type.googleapis.com/chunkchef.v1.billing.QuotaExceededDetail. Wenn Sie auf diese Zeichenkette prüfen, passen Sie sie an.

Endpunkte, Request- und Response-Strukturen sowie die Domains hotdoc.io / api.hotdoc.io bleiben unverändert.

2026-07-28 — OpenAPI-Spezifikation

  • Maschinenlesbare Spezifikation veröffentlicht unter /openapi.yaml — OpenAPI 3.0.3, generiert aus den Protobuf-Definitionen des Dienstes und deckt die fünf öffentlichen Jobs-Operationen ab (POST /v1/jobs/upload, POST /v1/jobs, GET /v1/jobs/{id}, GET /v1/jobs/{id}/result, GET /v1/jobs). Übergeben Sie die Datei einem beliebigen OpenAPI-fähigen Generator, um einen Client zu erzeugen; diese handgeschriebene Referenz bleibt die ausformulierte Dokumentation.
  • Verhaltensänderung — die Seitengröße von GET /v1/jobs ist jetzt begrenzt. pageSize liegt standardmäßig bei 50 und ist auf 200 gedeckelt. Ein Aufruf ohne pageSize lieferte zuvor den gesamten Auftragsverlauf in einer Antwort. Wenn Sie sich darauf verlassen haben, blättern Sie mit pageToken durch.
  • Verhaltensänderung — ein pageToken, das sich nicht mehr auflösen lässt, liefert 400. Zuvor begann ein solches Token die Auflistung ohne jeden Hinweis wieder auf der ersten Seite, sodass Sie bereits gesehene Einträge erneut erhalten konnten. Behandeln Sie das 400 als „der Cursor gilt nicht mehr, neu beginnen ohne pageToken”.
  • Behoben — das Blättern durch GET /v1/jobs überspringt und wiederholt keine Aufträge mehr. Der Cursor stützte sich auf eine andere Spalte als die, nach der die Liste sortiert war, sodass eine mehrseitige Auflistung einzelne Aufträge verlieren und andere doppelt zurückgeben konnte.

2026-07-24 — K-Konsens-Vertrauenssignal

  • Neues Feld consensus (optional) bei POST /v1/jobs — opt-in, setzt responseSchema voraus (sonst mit 400 abgelehnt). consensus.mode legt die Anzahl der Durchläufe fest: CONSENSUS_MODE_TWO_RUNS (2, eine Instabilitäts-Probe), CONSENSUS_MODE_THREE_RUNS (3, empfohlen) oder CONSENSUS_MODE_FIVE_RUNS (5, maximale Prüftiefe). hotdoc führt jeden Chunk k-mal mit Ihrem Schlüssel aus und stimmt Feld für Feld (relative Mehrheit) über die Antwort ab.
  • Neues Ergebnisfeld llm[].consensus — k, runsVotable, minAgreement, incomplete und disagreements[] (konkurrierende variants[] mit Durchlaufzahlen und ob sie included — die Abstimmung gewonnen haben). Zeigt Ihnen, bei welchen Feldern das Modell stabil war und bei welchen es geschwankt hat, zum k-fachen Token-Preis auf Ihrem Schlüssel. Siehe „Konsens-Durchläufe” in der Job-API-Dokumentation.

2026-07-15 — Chunk-Merge

  • Neues Feld merge (optional) bei POST /v1/jobs — optionales serverseitiges Zusammenführen der Modellantworten je Chunk zu einem Gesamtergebnis für das ganze Dokument. merge.scope wählt Zusammenführen je Datei (MERGE_SCOPE_FILE, Standard) oder über den ganzen Job (MERGE_SCOPE_JOB); merge.conflictPolicy legt fest, wie widersprüchliche Feldwerte aufgelöst werden (MERGE_CONFLICT_POLICY_FIRST_NON_NULL standardmäßig, oder MERGE_CONFLICT_POLICY_MAJORITY); merge.dedupeBy aktiviert die dateiübergreifende inhaltliche Deduplizierung anhand von JSON-Feldnamen (nur JSON + responseSchema; leer behält das sichere Standardverhalten bei, nur technische Deduplizierung).
  • Neues Ergebnisfeld merged[] — ein Eintrag je Datei (oder einer je Job bei scope=job) mit dem kombinierten content, schemaValid (wenn responseSchema gesetzt war), conflicts[], den Zählern dedupeRemovedTechnical/dedupeRemovedContent sowie mergeIncomplete/incompleteChunks, wenn ein Chunk nicht sicher zusammengeführt werden konnte. Die bestehenden llm[]-Zeilen je Chunk bleiben unverändert und weiterhin verfügbar. Dies schließt den offenen Hinweis „der Dienst fügt die Chunks weiterhin nicht zusammen” vom 2026-06-24 — Zusammenführen ist jetzt verfügbar, optional und standardmäßig deaktiviert. Siehe „Zusammenführen von Chunk-Ergebnissen” in der Job-API-Dokumentation.

2026-07-14 — Strukturierte Ausgabe (JSON Schema)

  • Neues Feld responseSchema (optional) bei POST /v1/jobs — ein in sich geschlossenes JSON Schema (Roh-String; nur interne #/$defs, ≤128 KiB, Tiefe ≤64, ≤10000 Knoten), gegen das hotdoc die JSON-Antwort des Modells validiert. Für OpenAI/Grok muss es mit der strict-Teilmenge kompatibel sein (jede Eigenschaft in required, Optionalität über type: [..., "null"], additionalProperties: false); ein in dieser Teilmenge geschriebenes Schema funktioniert unverändert bei allen Providern. Ein ungültiges Schema wird bei der Job-Erstellung mit 400 abgelehnt.
  • Neue Ergebnisfelder llm[].schemaValid / llm[].schemaErrors — werden nur für Dateien mit einem einzigen Chunk gemeldet. Eine nicht konforme Antwort wird trotzdem in content zurückgegeben, aber der Job endet als JOB_STATUS_PARTIAL statt JOB_STATUS_COMPLETE. Provider, für die hotdoc strukturierte Ausgaben emuliert (DeepSeek, Xiaomi), erhalten vor der Bewertung einen automatischen Korrekturversuch.

2026-07-09 — Extraktionsmodus

  • Neues Feld extractionMode (optional) bei POST /v1/jobs — EXTRACTION_MODE_HYBRID (Optimierte Hybrid-Extraktion, der Standard) lässt den Konverter je Datei entscheiden, ob Text direkt extrahiert oder OCR verwendet wird; EXTRACTION_MODE_OCR_ALWAYS erzwingt neuronale OCR für jede Datei. Dazu ein neuer Konto-Standard, konfigurierbar im Dashboard unter Einstellungen, der gilt, wenn ein Job extractionMode weglässt.

2026-07-08 — Öffentlicher Playground

  • /playground auf der Website — testen Sie hotdoc ohne Registrierung: Datei hochladen, vorgefertigten Prompt ausführen, Ergebnis direkt im Browser ansehen.
  • Neue anonyme Demo-Endpunkte, /v1/demo/*: Datei hochladen, Demo-Job erstellen, dessen Ergebnis abfragen und ihn nach der Registrierung einem echten Konto zuordnen. Sitzungen werden per Cookie verfolgt (kein Login) und sind auf 3 Durchläufe pro Sitzung plus ein gemeinsames Tagesbudget für alle anonymen Besucher begrenzt; Ergebnisse werden gekürzt. Dies ist additiv — die authentifizierte /v1/jobs-API bleibt unverändert.

2026-06-30 — Multi-Provider-OCR (BYOK)

Brechend. Die OCR-Stufe nimmt jetzt ocr.{provider, model, providerKey} (vorher ocr.mistralApiKey). Wählen Sie einen beliebigen unterstützten Provider — Mistral ist der Standard (mistral-ocr-latest). model ist erforderlich. Neue OCR-Fehlermarker (provider_auth_failed, provider_key_required, rate_limited, ocr_timeout, ocr_backend_*, too_many_pages) ersetzen mistral_key_required.

2026-06-26 — Idempotenz-Schlüssel

POST /v1/jobs nimmt idempotencyKey. Eine Wiederholung mit demselben Schlüssel und identischen Parametern gibt den ursprünglichen Job zurück; derselbe Schlüssel mit anderen Parametern gibt 400 zurück.

2026-06-24 — Webhooks zum Job-Abschluss

  • Neue Felder webhookUrl und webhookSecret (beide optional) beim Erstellen eines Jobs. webhookUrl ist ein absoluter http/https-Endpunkt; der Dienst sendet ihm einmal ein POST mit einem JSON-Body (job_id, account_id, status, finished_at), wenn der Job einen terminalen Status erreicht. webhookSecret ist ein HMAC-Secret: Wenn gesetzt, enthält jede Anfrage die Header X-Hotdoc-Timestamp und X-Hotdoc-Signature (sha256=hex(hmac_sha256(secret, "<ts>.<body>"))). Beide Felder werden nur als Eingabe entgegengenommen und tauchen niemals in Antworten auf. Wiederholungsrichtlinie: bis zu 6 Versuche mit Verzögerungen von 1 m / 5 m / 15 m / 30 m / 30 m. Details siehe „Webhooks”.

2026-06-24 — strukturbewusstes Chunking und konfigurierbare Chunk-Größe

  • Strukturbewusstes Chunking des Textes. Langer erkannter Text wird jetzt entlang der Strukturgrenzen seines Formats geschnitten (Markdown / HTML / XML / plain): Tabellen werden nicht mitten in einer Zeile zerrissen (die Kopfzeile einer Tabelle wird in jedem Chunk wiederholt), und der Kontext der Abschnittsüberschriften bleibt erhalten. Das bisherige Verhalten (Chunks als separate llm[]-Zeilen mit chunkIndex / chunkTotal) bleibt unverändert — der Dienst fügt die Chunks weiterhin nicht zusammen.
  • Neues Feld neural.chunkBudgetTokens (optional) beim Erstellen eines Jobs — Token-Budget pro Chunk für das Kontextfenster Ihres Modells; Bereich 16000–2000000, standardmäßig der konservative Wert des Dienstes. Die Antwort gibt das tatsächlich wirksame Budget zurück.
  • Neues Feld ocr[].outputFormat im Job-Ergebnis — das Format des erkannten Textes (markdown / html / xml / plain).