Ein Kunde — ein Eagle-Doc-„Sub-Business“ — ist ein reines Zuordnungs-Label. Er hat keinen Login, keinen API-Schlüssel und keine eigene Rechnung. Sie ordnen eine Anfrage einem Kunden zu, indem Sie einen Zuordnungs-Header zusammen mit Ihrem Business-API-Schlüssel senden.
Die Zuordnung macht aus einer einzelnen Business-Integration eine mandantenfähige: Sie trennt Nutzung, Dokumente und gelernte RAG-Beispiele pro Kunde — während alles weiterhin in Ihrem einen Business-Abonnement zusammenläuft.
🏷️
Ein Header, gesendet mit einem Business-Schlüssel
Senden Sie genau einen der Header x-sub-business-ref oder x-sub-business-id, zusammen mit einem APIB-…-Business-API-Schlüssel (oder dem Schlüssel eines gewrappten persönlichen Kontos). Alles Übrige an der Anfrage bleibt identisch.
Zwei Zuordnungs-Header
Wählen Sie pro Anfrage genau einen Header. Beide verweisen auf dasselbe Konzept — einen Kunden —, unterscheiden sich aber darin, wem die Kennung gehört und was bei einem unbekannten Wert passiert.
x-sub-business-id strikt
x-sub-business-ref Zero-Touch
Zu sendender Wert
Eine Eagle-Doc-Sub-Business-id, die Sie zuvor erhalten haben (über die Verwaltungs-API oder das Dashboard).
Ihre eigene Kundennummer — eine beliebige Kennung, die Ihr System bereits verwendet.
Muss zuerst existieren
Ja — der Kunde muss bereits existieren.
Nein — wird bei der ersten Nutzung automatisch angelegt.
Unbekannter Wert
Wird wie ein ungültiger Schlüssel abgelehnt: 403 „API key invalid“.
Legt den Kunden an und führt die Anfrage anschließend aus.
Am besten für
Das Aufspüren von Integrationsfehlern und die explizite Kontrolle darüber, welche Kunden existieren.
Reibungsloses Onboarding — kein Zustand zu speichern, keine Vorab-Registrierung.
🚫
Senden Sie niemals beide Header gleichzeitig
Das Senden von x-sub-business-id und x-sub-business-ref in derselben Anfrage liefert 400 — messageCode 8011 (SUB_BUSINESS_HEADER_CONFLICT): „Send either x-sub-business-id or x-sub-business-ref, not both.“
✅
Empfohlener Standard
Bevorzugen Sie für die meisten Integrationen x-sub-business-ref: Es erfordert keine Vorab-Bereitstellung und keine gespeicherten Eagle-Doc-IDs. Greifen Sie zu x-sub-business-id, wenn Sie strikte, sofort fehlschlagende Kontrolle wünschen.
Zero-Touch: x-sub-business-ref
Senden Sie Ihre eigene Kundennummer in x-sub-business-ref. Bei der ersten Nutzung legt Eagle Doc das Sub-Business automatisch für Sie an — Sie registrieren nie etwas vorab.
Der Name des neuen Kunden wird auf die Referenz selbst gesetzt, die Referenz wird als externalClientRef gespeichert, und die Beschreibung lautet „auto-created from x-sub-business-ref“. Sie können den Kunden später im Dashboard umbenennen, doch die Referenz bleibt der Auflösungsschlüssel.
Jede spätere Anfrage mit derselben Referenz wird demselben Kunden zugeordnet. Referenzen sind pro Business unter den aktiven Kunden eindeutig und sind nach dem Löschen eines Kunden erneut verwendbar.
Ordnen Sie eine Beleg-Extraktion mit Ihrer eigenen Kundennummer zu:
import requests
resp = requests.post(
"https://de.eagle-doc.com/api/receipt/v3/processing",
headers={
"api-key": "APIB-your-business-key",
"x-sub-business-ref": "A-1023", # your own client number
},
files={"file": open("receipt.jpeg", "rb")},
)
print(resp.json())
import fs from "node:fs";
const form = new FormData();
form.append("file", new Blob([fs.readFileSync("receipt.jpeg")]), "receipt.jpeg");
const resp = await fetch("https://de.eagle-doc.com/api/receipt/v3/processing", {
method: "POST",
headers: {
"api-key": "APIB-your-business-key",
"x-sub-business-ref": "A-1023", // your own client number
},
body: form,
});
console.log(await resp.json());
⚠️
Eine leere Referenz wird abgelehnt
Das Senden eines leeren x-sub-business-ref liefert 400 — messageCode 8007. Senden Sie einen nicht-leeren Wert oder lassen Sie den Header ganz weg.
Strikt: x-sub-business-id
Senden Sie die Eagle-Doc-Sub-Business-id in x-sub-business-id. Die ID muss bereits existieren und zu Ihrem Business gehören — Sie erhalten sie über die Kundenverwaltungs-API oder das Dashboard.
Eine fremde oder unbekannte ID schlägt genau wie ein ungültiger Schlüssel fehl: 403 — messageCode 3009 („API key invalid“). Das ist bewusst so — es wird nie preisgegeben, ob eine bestimmte ID existiert.
Ordnen Sie eine Beleg-Extraktion mit einer Eagle-Doc-Sub-Business-ID zu:
import fs from "node:fs";
const form = new FormData();
form.append("file", new Blob([fs.readFileSync("receipt.jpeg")]), "receipt.jpeg");
const resp = await fetch("https://de.eagle-doc.com/api/receipt/v3/processing", {
method: "POST",
headers: {
"api-key": "APIB-your-business-key",
"x-sub-business-id": "66cc0f2a4b1e8a0012ab34cd", // an Eagle Doc sub-business id
},
body: form,
});
console.log(await resp.json());
Wann die Zuordnung erlaubt ist
Zuordnungs-Header werden nur in einem Business-Kontext berücksichtigt:
🔐
Wo die Zuordnung funktioniert
Gültig mit einem APIB-…-Business-API-Schlüssel oder mit dem Schlüssel eines gewrappten persönlichen Kontos.
Das Senden eines der beiden Header mit einem einfachen (nicht gewrappten) persönlichen API-…-Schlüssel liefert 400 — messageCode 8002 (SUB_BUSINESS_NOT_ALLOWED): „Sub-business not allowed.“
Datentrennung pro Kunde
Sobald eine Anfrage zugeordnet ist, hält Eagle Doc die Daten dieses Kunden getrennt:
Die Nutzung wird pro Kunde gezählt, sodass Sie jeden Kunden unabhängig abrechnen oder auswerten können — während das Kontingent weiterhin in Ihrem Business zusammenläuft.
Dokumente und Datensätze werden mit dem Kunden markiert, der sie erzeugt hat.
RAG-Beispiele sind pro Kunde abgegrenzt, sodass Korrekturen, die Sie für einen Kunden lehren, nie zu einem anderen übergehen.
Die meisten Teams benötigen dies nie — die Zero-Touch-Zuordnung legt Kunden für Sie an. Die optionale Kundenverwaltungs-API richtet sich an Teams, die Kunden lieber vorab bereitstellen oder von Anfang an umbenennen.
👤
Echter Benutzer-Token erforderlich
Diese Endpunkte erfordern einen echten Benutzer-Token — einen persönlichen API-…-Schlüssel oder eine Dashboard-Sitzung. Das Erstellen, Aktualisieren und Löschen von Kunden erfordert die Rolle ADMIN oder höher; das Auflisten erfordert MEMBER oder höher. APIB-…-Business-API-Schlüssel werden mit 403 „API key not permitted“ (Code 3010) zurückgewiesen.
Parameters
Name
Description
api-key (header)
Real-user token: a personal API-… key with role ADMIN or higher. APIB-… business keys are rejected.
businessId (path)
The id of your business (the parent).
body (application/json)
name is required; description and externalClientRef are optional.
The caller is not a real user with role MEMBER or higher, or an APIB-… business key was used (messageCode 3010).
Parameters
Name
Description
api-key (header)
Real-user token with role ADMIN or higher. APIB-… business keys are rejected.
businessId (path)
The id of your business (the parent).
subBusinessId (path)
The id of the client to update.
body (application/json)
All fields optional; only the ones you send are changed.
{
"name": "Client A (EU)",
"description": "Renamed",
"externalClientRef": "CRM-1001"
}
Responses
Code
Description
200
Updated. Returns the sub-business Business object.
400
messageCode 8010 (SUB_BUSINESS_REF_TAKEN) when the externalClientRef is already used by a live sibling: “Client reference already in use”.
404
messageCode 8001 when the sub-business does not exist.
Parameters
Name
Description
api-key (header)
Real-user token with role ADMIN or higher. APIB-… business keys are rejected.
businessId (path)
The id of your business (the parent).
subBusinessId (path)
The id of the client to delete.
Responses
Code
Description
200
Soft-deleted. Historical usage keeps referencing the client, and its externalClientRef becomes reusable for a new client.
404
messageCode 8001 when the sub-business does not exist.
🔗
Die beiden Header verknüpfen
Wenn Sie externalClientRef hier auf denselben Wert setzen, den Sie in x-sub-business-ref senden, verweisen beide Header auf denselben Kunden.
Lieber klicken? Verwalten Sie Kunden unter Business → Einstellungen → Sub-Businesses.
Fehlerreferenz
Jeder Fehler verwendet den standardmäßigen Eagle-Doc-Fehlerkörper; prüfen Sie messageCode, um präzise zu verzweigen:
{
"httpCode": 400,
"httpCodeName": "BAD_REQUEST",
"messageCode": 8011,
"message": "Conflicting sub-business headers",
"messageDetails": ["Send either x-sub-business-id or x-sub-business-ref, not both."],
"data": null
}
messageCode
HTTP
Wann es auftritt
8002
400
Ein Zuordnungs-Header wurde mit einem einfachen (nicht gewrappten) persönlichen API-…-Schlüssel gesendet — SUB_BUSINESS_NOT_ALLOWED.
3009
403
Eine unbekannte oder fremde x-sub-business-id; gemeldet als „API key invalid“, sodass keine Existenz preisgegeben wird.
8010
400
Eine externalClientRef, die bereits von einem aktiven Kunden verwendet wird — SUB_BUSINESS_REF_TAKEN (manuelles Anlegen oder Aktualisieren).
8011
400
Sowohl x-sub-business-id als auch x-sub-business-ref wurden in einer Anfrage gesendet — SUB_BUSINESS_HEADER_CONFLICT.
8007
400
Der Header x-sub-business-ref war leer.
8001
404
Das referenzierte Sub-Business wurde nicht gefunden (Verwaltungs-API).
3010
403
Ein APIB-…-Business-API-Schlüssel wurde auf einem Verwaltungs-Endpunkt verwendet — „API key not permitted“. Verwalten Sie Kunden mit einem persönlichen Schlüssel oder dem Dashboard.
Support
💬
Wir helfen Ihnen gerne
Sie bauen Ihre Integration für mehrere Kunden auf und etwas ist unklar? Wir helfen Ihnen gerne, damit Ihr Projekt gelingt.