Dokumentation der API

Referenz der API

Die Schnittstelle /v1 ist die versionierte, lesende API für Kundensysteme. Sie hat 68 Endpunkte, 65 GETs und drei bewusste POSTs mit reiner Lesesemantik. Jeder Endpunkt authentifiziert sich wie unter Authentifizierung beschrieben, antwortet mit reinem JSON (der Export des Prüfprotokolls antwortet mit CSV, die Dokumente mit PDF) und ändert nichts in Ihrem Arbeitsbereich. Dieselben Daten stehen Assistenten mit KI über MCP zur Verfügung.

Diese Seite ist der Leitfaden. Die Referenz auf Feldebene ist das aktive Dokument nach OpenAPI unter https://api.stonewake.ai/openapi.json: das maschinenlesbare Schema für jede Antwort, jeden Anfrageparameter und jede Fehlerform. Die Routen unter /v1 tragen dort das Tag v1, und die beiden unten genannten abgelösten Routen tragen dort deprecated: true.

Unten kommen zwei getrennte Kennungssysteme vor, die sich auf keiner Route vermischen. node_id ist die Kennung eines Graphknotens, die Kennung, die Treffer aus /v1/search tragen und die jede Route unter /v1/nodes/... erwartet; entity_id ist das eigene Kennungssystem des geschlossenen Institutionenverzeichnisses (/v1/entities).

Aufrufer und Teamumfang

GET /v1/me, die aufrufende Berechtigung und die Teams, die ihre Lesezugriffe abdecken. credential ist api_key oder user, und team_scope enthält all_teams und die genannten teams, jeweils mit id und name.

Ein Arbeitsbereich kann mehrere Teams umfassen, etwa eines je Desk, und jedes Team führt seinen eigenen Bestand. Ein Schlüssel liest genau ein Team, nämlich das, für das er ausgestellt wurde (siehe Schlüssel und Zugangsverwaltung). Ein Schlüssel ohne Team und jeder Schlüssel, der ausgestellt wurde, bevor sich ein Team wählen ließ, liest das Standardteam des Arbeitsbereichs. all_teams ist nur für angemeldete Administratoren und Complianceverantwortliche wahr, nie für einen Schlüssel. Jede Zeile des Deal Books, des Portfolios, des Feeds der Statusänderungen, der Screeningliste, der Rechercheläufe und des Feeds der Entwicklungen trägt team_id und team_name, sodass stets erkennbar ist, zu wessen Bestand eine Zeile gehört. Ein Screening mit team_id gleich null ist ein arbeitsbereichsweites Screening, das jedes Team liest.

Ein Recherchelauf gehört dem Team, das ihn gestartet hat. Ein Schlüssel liest, wie jeder Leser eines einzelnen Teams, nur die Rechercheläufe seines eigenen Teams und deren Entwicklungen, und die run_id eines anderen Teams beantwortet 404 genau wie eine unbekannte. Angemeldete Administratoren und Complianceverantwortliche lesen die Rechercheläufe aller Teams. Ein Lauf mit team_id gleich null stammt aus der Zeit vor den Teamumfängen, und nur diese teamübergreifenden Leser lesen ihn.

Portfolio

GET /v1/portfolio, der überwachte Bestand, ein Eintrag je Engagement mit aktuellem Status, Score, wichtigsten Signalen, letzter Statusänderung und geltender Kreditüberprüfung (review, null, wenn nie überprüft, und review_overdue, sobald das Datum der nächsten Überprüfung verstrichen ist, nie bei einem deaktivierten Engagement). Sortiert nach Schwere, Rot zuerst. include_inactive=true nimmt deaktivierte Engagements auf.
GET /v1/portfolio/summary, Statuszählungen für den aktiven Bestand, transitions_30d, die Zahl der Übergänge der letzten 30 Tage (jeder Eintrag des Feeds, auch die erste Einschätzung eines Engagements), status_changes_30d, die Statusänderungen darunter (die erste Einschätzung eines Engagements ist eine Neuaufnahme in den Bestand, keine Änderung), und reviews_overdue, die aktiven Engagements, deren Datum der nächsten Überprüfung verstrichen ist.
GET /v1/portfolio/transitions, der Feed der Statusänderungen, neueste zuerst. since (ein Zeitstempel nach ISO 8601) begrenzt den Feed. Jede Zeile trägt ihre cause, abgeleitet aus den beiden Einschätzungen, die sie vergleicht, mit kind (added für die erste Einschätzung eines Engagements, sonst change), available (false, wenn sich eine der beiden Einschätzungen nicht lesen lässt; dann wird kein Treiber behauptet), die drivers (die Signale, deren Änderung den Status bewegt hat, mit ihrem Band davor und danach, der Übersteuerung override, die der neue Lauf angewendet hat, und ihren Quellenkennungen; hat sich nur die Übersteuerung eines Treibers geändert, ist sein Band davor und danach dasselbe), more_drivers, stopped_scoring (wie viele Treiber, genannt oder gezählt, vorher ein Band hatten und jetzt keines), rules_changed, die Kennungen beider Einschätzungen und record, den Registereintrag hinter dem führenden Treiber, wenn einer dahintersteht. Siehe Kreditüberprüfungen und Statusänderungen.
GET /v1/portfolio/{exposure_id}/reviews, die Historie der Kreditüberprüfungen eines Engagements, neueste zuerst, der erste Eintrag ist also die geltende Überprüfung. Jede Überprüfung trägt ihre disposition (no_action, watch_list, intensified_care oder escalated), note, next_review_on und reviewed_at. Die Historie wird nur fortgeschrieben. Verantwortliche und Prüfende sind Identitäten von Mitgliedern und werden hier nicht ausgeliefert.
GET /v1/portfolio/reviews-due listet die Kreditüberprüfungen, die heute (UTC) Aufmerksamkeit verlangen, die Liste des Dashboards mit unveränderten Regeln. overdue enthält die aktiven Engagements, deren Datum der nächsten Überprüfung verstrichen ist, und due_soon jene, die innerhalb von window_days (14) fällig werden, heute eingeschlossen, jeweils die frühesten zuerst und höchstens 50 Einträge, während overdue_total und due_soon_total jede zählen. never_reviewed zählt die aktiven Engagements, die nie überprüft wurden, und as_of ist das Vergleichsdatum. Jede Zeile nennt ihre exposure_id, team_id, team_name, node_id, label, den aktuellen status, die disposition und next_review_on. Deaktivierte Engagements werden nie gelistet. Dieselbe Teamzuordnung wie GET /v1/portfolio. Verantwortliche sind Identitäten von Mitgliedern und werden hier nicht ausgeliefert.
POST /v1/portfolio/import, Vorschau eines Bestandsimports. Der Body trägt den Bestand als Text als CSV in csv (höchstens 2.000 Zeilen); jede Zeile wird allein über ihre Registerkennung zugeordnet und mit ihrem Ergebnis für den Bestand Ihres Teams und dem Grund beantwortet; die Zeilen kommen seitenweise über limit (höchstens 100) und offset, während counts und total die ganze Datei umfassen. dry_run ist hier immer true, es wird also nichts geschrieben, und übernommen wird ein Import im Dashboard. Dateiformat und Ergebnisse beschreibt Bestandsimport.
Ein Einzelunternehmen, ein Unternehmen, das laut den Registern das Geschäft einer natürlichen Person ist (der deutsche Registerauszug entscheidet, wenn es einen gibt; ohne ihn genügt eine dieser Quellen, der Zusatz e.K. oder e.U. in der Firma, die Rechtsform eines Einzelunternehmens aus dem GLEIF Eintrag oder einem anderen Register oder die GLEIF Kategorie Sole Proprietor, während eine Abweichung zur Prüfung festgehalten wird), bleibt mit seinen Registerangaben, Insolvenzbekanntmachungen, Nachrichten und sozialen Medien im Bestand und wird nie bewertet. Seine Zeile in /v1/portfolio trägt den status sole_trader mit leeren Bewertungsfeldern, ohne top_signals und ohne last_transition, die Übersicht zählt es unter sole_trader, der Verlauf führt keine Statusänderung dazu, und /v1/portfolio/reviews-due nennt seinen status sole_trader. Jeder Abruf, der das Unternehmen eines Einzelkaufmanns ausliefert, schreibt den Zugriffseintrag wie für eine natürliche Person, /v1/search liefert es mit score null, und Bericht und Paket einer Registergegenpartei, die ein Einzelunternehmen ist, antworten mit 404, wie sein Unternehmensprofil.

Risiko je Unternehmen

GET /v1/nodes/{node_id}/risk, die aktuelle Risikoeinschätzung Ihres Teams zu einem Unternehmen, mit den bewerteten Signalzeilen und ihren Quellenangaben. Die Antwort führt den name des Unternehmens (denselben Namen, den Zeilen aus /v1/portfolio als label liefern) und unterscheidet zwischen „nicht gehalten“, „gehalten, aber noch nicht bewertet“ und „bewertet“. Ein Einzelunternehmen antwortet mit sole_trader true und ohne Einschätzung, ob gehalten oder nicht.

Signalzeilen tragen ein band von red, amber, green oder null. Ein band von null bedeutet, dass sich das Signal aus den zu diesem Unternehmen verfügbaren Daten nicht bewerten ließ; die Zeile wird trotzdem ausgeliefert, und ihr note sagt warum, damit Unbeobachtbares benannt und nicht verschwiegen wird. Genau die unbewerteten Zeilen halten die completeness einer Einschätzung unter 1, und evidence_completeness zählt ausschließlich Bänder, die durch tatsächliche Nachweise gedeckt sind (nie Bänder, die ein konservatives Bewertungsschema bei fehlenden Daten angenommen hat). Damit ist es der strengere der beiden Werte. Die Untergrenze für den Status insufficient liest reachable_share, siehe unten. Die Zeile zur Zinsdeckung liest das EBIT im Verhältnis zum Zinsaufwand. Nennt der Abschluss für die Periode keinen Zinsaufwand, liest sie das EBIT im Verhältnis zu den Finanzierungsaufwendungen, die auch Gebühren und andere Finanzierungskosten enthalten. Bei positivem EBIT fällt diese Deckung daher nie höher aus als eine allein auf Zinsen, und ihre note sagt, welche Zeile gelesen wurde. Die Signalzeile zum Insolvenzantrag wertet von einem deutschen Insolvenzgericht angeordnete Sicherungsmaßnahmen als anhängigen Antrag, mit dem band amber und der Bekanntmachung als Quelle, so wie sie im Vereinigten Königreich einen Antrag auf Abwicklung einer Gesellschaft wertet. Findet die Signalzeile zum Insolvenzantrag in Deutschland nichts, heißt das, dass keine solche Anordnung bekanntgemacht wurde, nicht, dass kein Antrag anhängig ist, denn ein Gericht muss eine Anordnung nur bekanntmachen, wenn sie die Verfügungsbefugnis des Schuldners beschränkt. Eine grüne Zeile eines Signals aus Registerereignissen, ob mit oder ohne Quellenangabe, stützt sich auf einen Registerabgleich, der innerhalb des Aktualisierungsintervalls der Quelle zuzüglich einer Karenz von sechs Stunden lief und bis zum Beginn des Betrachtungszeitraums des Signals zurückreicht; reicht die Erfassung einer Quelle noch nicht so weit zurück, bleibt die Zeile unbewertet, und ihr note nennt, wie weit die Erfassung zurückreicht. Bei einem Register, das in ganzen Ausgaben veröffentlicht wird, gilt eine Prüfung, bei der der Herausgeber angibt, dass die bereits geladene Ausgabe weiterhin seine neueste ist, als Registerabgleich, sodass Tage ohne neue Ausgabe, etwa ein Wochenende, die Zeile bewertet lassen; eine Prüfung, die den Herausgeber nicht erreicht, eine Antwort erhält, die nicht die veröffentlichte Datei ist, oder die vom Herausgeber angegebene Ausgabe nicht lesen kann, zählt nicht, ebenso wenig eine Ausgabe, die älter ist, als die übliche Pause des Herausgebers zulässt (fünf Tage bei SEC EDGAR, 40 Tage bei INSEE Sirene), und nach Ablauf des Aktualisierungsintervalls und der Karenz wird die Zeile unbewertet, und ihr note nennt den Tag des letzten Registerabgleichs. Für alle Zeilen, die SEC EDGAR speist, auch die Zeile zu Zweifeln an der Unternehmensfortführung, muss SEC EDGAR außerdem seit der Verknüpfung des Unternehmens mit seiner Kennung bei SEC EDGAR vollständig durchsucht worden sein; bis dahin bleiben diese Zeilen unbewertet, und ihr note sagt das. Companies House charges liest Unternehmen einzeln, daher braucht eine grüne Zeile zu neuen Sicherheiten außerdem einen Abruf der vollständigen Liste der Sicherheiten dieses Unternehmens durch den regelmäßigen Abgleich innerhalb dieses Intervalls (ein Unternehmen ohne Sicherheiten zählt ebenso, die Prüfung einer einzelnen Sicherheit oder eine einzeln gestreamte Sicherheit nie), und sie deckt die vollen zwei Jahre erst ab, wenn die vorhandene Historie der Sicherheiten geladen ist; bis dahin bleibt sie unbewertet, und ihr note sagt das.

Jede Signalzeile nennt außerdem ihren state, also evidenced, register_quiet (ein angebundenes Register wurde gelesen und verzeichnet nichts), gap, awaiting_bank_input oder not_applicable. Eine Lücke nennt in gap_reason ihren Grund, etwa register_not_integrated, wenn noch keine von uns angebundene Quelle das Signal für dieses Unternehmen liefert, oder no_public_register, wenn die Rechtsordnung des Unternehmens dafür kein öffentliches Register führt. Eine Lücke, die kein frei zugängliches landesweites Register schließen kann, lautet paid_register_excluded (in den USA führt jeder Bundesstaat sein eigenes Unternehmensregister und sein eigenes Register für Sicherungsrechte, und Akten der Bundesgerichte werden über PACER pro Seite verkauft), und weil kostenpflichtige Register grundsätzlich nicht zu unseren Quellen gehören, zählt sie wie no_public_register als erklärt. Eine bewertete Zeile nennt ihre Nachweisstufe grade, von A (ein gesetzliches Register, offengelegte Jahresabschlüsse oder eine Bankbestätigung) bis D (ein Treffer allein über den Namen). Ein Signal, dessen Quellen alle nur andere Länder abdecken, bleibt aus der Einschätzung des Unternehmens heraus und wird weder geliefert noch gezählt, ein britisches Unternehmen liest also nie eine Zeile aus US Meldungen als fehlend; ein Signal, das Quellen des eigenen Landes des Unternehmens liefern und das wir noch nicht lesen können, ist eine Lücke, und not_applicable bleibt Signalen vorbehalten, die es für das Unternehmen überhaupt nicht geben kann. Dieselbe Regel gilt für Personen, und ein Unternehmen oder eine Person ohne bekanntes Land behält jedes Signal. Die Einschätzung führt seen_share (den Gewichtsanteil der anwendbaren Signale, die tatsächlich beobachtet wurden), explained_share (den beobachteten Anteil zuzüglich der endgültigen Lücken, die kein frei zugängliches landesweites Register schließen kann), reachable_share (den beobachteten Anteil der Signale, die eine angebundene Quelle für die Rechtsordnung des Unternehmens liefern kann) und coverage_line, einen bis drei englische Sätze, die die abgedeckten Signale, die Lücken mit ihren Gründen und die nicht anwendbaren Signale zählen. Die Untergrenze für den Status insufficient liest reachable_share. Offengelegte Abschlüsse, die die Strecke eines Signals außerhalb des eigenen Landes des Unternehmens erfasst hat (die ESEF Abschlüsse einer britischen plc), behalten ihre Zeile, die gegen seen_share zählt, ein Unternehmen aber nie insufficient macht, und ein Mindeststatus amber, der auf Nachweisen der Stufe A oder B beruht, hält den Status unterhalb dieser Untergrenze auf amber. Zeilen aus /v1/portfolio führen alle drei Anteile.

Ein gehaltenes Unternehmen führt zudem entity_class, die Klasse, nach der seine Prüfungen ausgewählt werden (corporate, sovereign_or_public_body, bank, spv oder fund), ihre source (analyst_override, wenn Ihr Team die Klasse im Dashboard für die Position gesetzt hat, sonst die Registerregel, aus der sie abgeleitet wurde), ihre confidence, decided_at sowie derived_class, die Klasse allein nach den Registerangaben. Eine Bank wird nie mit Insolvenzmodellen für Unternehmen bewertet. Diese Zeilen und die Verschuldungskennzahlen für Unternehmen erscheinen als nicht anwendbar, auch wenn der Abschluss sie berechnen ließe. Stattdessen wird eine Bank nach ihrer eigenen Kapitalausstattung und Aktivqualität bewertet, in vier Zeilen, nämlich harte Kernkapitalquote, Quote notleidender oder überfälliger Kredite, Verschuldungsquote und Liquidität, gelesen über den LEI oder die RSSD der Federal Reserve aus der ersten Quelle, die die Bank führt, der EU weiten Transparenzübung der Europäischen Bankenaufsichtsbehörde, den eigenen Offenlegungen nach Säule 3 der britischen Banken (sechs britische Bankengruppen, HSBC Holdings, Barclays, NatWest Group, Standard Chartered, Santander UK Group Holdings und Nationwide Building Society, und sechs ihrer operativen Banken, Santander UK plc, HSBC UK Bank plc, HSBC Bank plc, Barclays Bank UK PLC, Barclays Bank PLC und National Westminster Bank) oder den Call Report Daten der FDIC. Jede andere britische Bank liest jede Zeile als Lücke. Eine britische Zahl aus den Schlüsselkennzahlen in value_display liest so, wie die Bank sie gedruckt hat, zum Beispiel "14.1%; UK CET1, Pillar 3 KM1", und die britische Quote notleidender Kredite, die berechnet ist, zeigt zwei Nachkommastellen. Das value_display einer bewerteten Zeile nennt nach einem Semikolon die Definition ihrer Zahl, zum Beispiel "0.78%; US noncurrent, not NPL", und ihre note nennt Quelle, Ausgabe, Stichtag, bei einer amerikanischen oder britischen Zahl die Bank, die sie gemeldet hat, mit dem Namen, den die FDIC oder GLEIF angibt, bei einer britischen Zahl das Dokument, aus dem sie gelesen wurde, die Kennung, über die sie zugeordnet wurde, und die vollständige Definition. Eine amerikanische Zahl wird nach Schwellen eingestuft, die für ihre eigene Definition gesetzt sind. Nur die Offenlegungen nach Säule 3 der britischen Banken veröffentlichen Liquiditätskennzahlen, daher bleibt die Zeile zur Liquidität jeder anderen Bank eine Lücke. Eine Bank, die in keiner der Ausgaben steht, die ihre Notiz nennt, eine Bank ohne erfassten LEI und ohne RSSD, ein LEI und eine RSSD, die zwei verschiedene Banken nennen, oder eine Ausgabe, die älter ist, als ihr Rhythmus erlaubt, liest jede Zeile als Lücke mit null als band und einer Notiz, die den Grund nennt, ebenso jede Bank, solange keine bis zum Tag der Einschätzung veröffentlichte Ausgabe geladen ist. Die vier Zeilen tragen das Gewicht der Zeilen, für die sie stehen, in completeness, evidence_completeness und den drei Anteilen. So behält eine Bank die Nenner desselben Unternehmens ohne Klasse, und nur eine tatsächlich gelesene Kennzahl hebt einen Anteil. Eine Zeile eines Unternehmensmodells, die für die Rechtsordnung der Bank keine angebundene Quelle erreicht, bleibt die Lücke, die sie für dasselbe Unternehmen ohne Klasse ist. Auch einen Status verbessert eine Klassenregel nie von sich aus. Die einzige Ausnahme ist eine Bank, deren Rot oder Gelb aus Unternehmensmodellen kam. Sie kann besser stehen als dasselbe Unternehmen ohne Klasse, aber nie besser als insufficient, solange keine ihrer eigenen Kennzahlen gelesen ist. Diese Ausnahme führt also nie zu Grün. Solange keine ihrer eigenen Kennzahlen gelesen ist, wird eine Bank nur grün, wenn dasselbe Unternehmen ohne Klasse grün ist. Ist eine gelesen, halten die Unternehmensmodelle ihren Status nicht mehr fest. Hier ist die Klasse nur lesbar; Ihre Analysten setzen sie im Dashboard.

GET /v1/entities/{node_id}/risk, abgelöste Parallelroute der Route darüber, für bestehende Aufrufer erhalten und im Schema nach OpenAPI mit deprecated: true gekennzeichnet. Neue Anbindungen verwenden /v1/nodes/{node_id}/risk.
GET /v1/risk-assessments/{assessment_id}, eine Einschätzung nach Kennung. Einschätzungen bilden eine ausschließlich fortgeschriebene Historie, die Kennung ist also ein dauerhafter Permalink.
GET /v1/nodes/{node_id}/company liefert ein Unternehmen so, wie es die Netzwerkansicht des Dashboards zeigt. identity nennt, was die vorliegenden Registereinträge zur Identität des Unternehmens angeben, soweit der jeweilige Eintrag es angibt. GLEIF nennt Name, LEI, Rechtsform, Land, Status und die Daten des LEI, Companies House Name, Registernummer, Gesellschaftstyp, Status, Gründungsdatum, eingetragenen Sitz und SIC Codes, der Handelsregisterauszug, wo einer abgerufen wurde, Registergericht und Registernummer, Sitz, Anschrift, Kapital, Gegenstand des Unternehmens und Bundesland, dazu kommen SEC EDGAR, das Schweizerische Handelsamtsblatt und der Betreibereintrag im Marktstammdatenregister. Kodierte Werte erscheinen als Klartext in der angefragten Sprache. Das gilt auch für die beiden reservierten Rechtsformcodes der GLEIF, 8888 für eine Rechtsform, die noch nicht in der Codeliste der GLEIF steht, und 9999 für einen Rechtsträger ohne eigene Rechtsform. Kapital, Gegenstand, Bundesland und Eintragungsdaten des Handelsregisterauszugs folgen direkt auf seine übrigen Angaben. Eine Angabe, die zwei Register gleichlautend machen, erscheint einmal, ein späteres Register, das sie anders angibt, nennt sich in der Bezeichnung (zum Beispiel Rechtsform laut GLEIF), und jede Angabe nennt in record_id den Eintrag aus identity_sources, auf den sie sich stützt. Jeder dieser Einträge trägt verified_at, wann sein Register ihn zuletzt bestätigt hat, neben retrieved_at, wann er zuerst abgerufen wurde. Mit locale gleich de kommen die Feldbezeichnungen und dieser Klartext auf Deutsch. risk_state ist portfolio, wenn Ihr Team das Unternehmen im Bestand hält, und risk liefert dann dieselbe Antwort wie /v1/nodes/{node_id}/risk. Andernfalls liefert risk die bei Aufruf erstellte Einschätzung für Ihr Team, die das Dashboard erstellt, wenn eine Person das Unternehmen öffnet oder ein Screening dazu startet und Ihr Arbeitsbereich keine aktuelle Einschätzung dazu hat, mit denselben Signalzeilen und einer exposure_id von null. Ein Einzelunternehmen hat den risk_state sole_trader ohne Einschätzung, ob gehalten oder nicht. risk_state lautet dann assessed, in_progress, solange eine erstellt wird, oder not_assessed mit einem risk_reason von allowance (das stündliche Kontingent an Einschätzungen des Arbeitsbereichs ist ausgeschöpft), failed (der letzte Lauf wurde nicht abgeschlossen) oder not_started (es wurde keine erstellt). Eine Anfrage an diese API liest nur und stößt nie eine Einschätzung an.

Bewertungsschema

GET /v1/risk-profiles, die Fassungen des Bewertungsschemas Ihres Teams, neueste zuerst.
GET /v1/risk-profiles/{version}, eine Fassung mit ihrer vollständigen Konfiguration.
GET /v1/risk-config, das Bewertungsschema, nach dem die Engagements Ihres Teams derzeit bewertet werden. version ist null, solange die eingebaute Voreinstellung aktiv ist.

Institutionenverzeichnis

GET /v1/entities, das Institutionenverzeichnis (Exportkreditagenturen, multilaterale Institutionen, Entwicklungsfinanzierer, Entwicklungsbanken, staatliche Agenturen und Banken, dazu die Fachpublikationen, die Transaktionen zitieren, gekennzeichnet mit kind trade_press), in Namensreihenfolge. Jeder Eintrag trägt kind_label, seine Art in Worten, und location_label, sein Land oder Multilateral bei einer multilateralen Institution.
GET /v1/entities/{entity_id}, der Stammdatensatz eines Verzeichniseintrags.

Suche

GET /v1/search?q=... findet ein Unternehmen über Namen oder Kennung (lei:5493..., eine reine Registernummer oder einen Namen). Treffer tragen die node_id, die die Knotenrouten sprechen, und node_type, dazu Jurisdiktion und Registerdaten. In einem Arbeitsbereich, in dem Personendaten eingeschaltet sind, werden auch die natürlichen Personen gefunden, die die Register nennen, nach allen Unternehmen, mit node_type person und einem score von null, denn eine Person wird nie bewertet. connected_sources benennt die Quellen, gegen die die Abfrage lief, sodass ein leeres Ergebnis zuordenbar ist. limit ist auf 25 gedeckelt. Bekannte Kurznamen und Abkürzungen wie VW oder Haspa stehen an erster Stelle, jeweils über den LEI ihrer juristischen Person zugeordnet, und eine Abfrage aus zwei Buchstaben wird nur beantwortet, wenn sie genau einer dieser Namen ist.

Die Suche antwortet mit einem eigenen Umschlag, nicht mit dem Standardumschlag für Listen, { "query": ..., "hits": [...], "connected_sources": [...] }, ohne die Schlüssel limit, offset und total.

Unternehmensknoten

Jede Knotenform trägt node_type, company oder person. In einem Arbeitsbereich, in dem Personendaten eingeschaltet sind, beantwortet der Knoten einer natürlichen Person den Knotenabruf, seine Einträge, seine Ereignisse und sein Netz wie der eines Unternehmens. Anderswo beantwortet die node_id einer Person dieselbe kanonische 404 wie eine unbekannte Kennung, ebenso bei einer Person, die der Verarbeitung ihrer Daten widersprochen hat. Finanzzahlen, Finanzierung, Sicherheitenstandorte, Branchen und Regionalkontext, Risiko und der Ausgangsknoten der Eigentümerkette sind Unternehmensabrufe, und die node_id einer Person beantwortet dort in jedem Arbeitsbereich 404.

GET /v1/nodes/{node_id} liefert die Identität eines Unternehmensknotens (Namen, Jurisdiktion und Registerkennungen), dazu jeden aktuellen Registereintrag als Beleg, die neuesten zuerst. records_total zählt die Einträge in records, und registers nennt für jedes Register die Anzahl als records_total, das Register mit dem neuesten Eintrag zuerst. Die Antwort wird gestreamt, während sie gelesen wird, und sie wächst mit dem Unternehmen, denn ein Unternehmen, das in einem Wertpapierregister geführt wird, kann über 100.000 Einträge halten, Dutzende Megabyte an Belegen. Solange andere Abrufe sehr großer Unternehmen laufen, kann ein weiterer mit 503 server_busy antworten; siehe Fehler und Anfragebegrenzungen. Eine Antwort, die nach 60 Sekunden noch gestreamt wird, bricht ab; lesen Sie ein sehr großes Unternehmen daher über die unten genannte Route für Einträge.
GET /v1/nodes/{node_id}/records ist der effiziente Weg, ein großes Unternehmen zu lesen. Die Route blättert die aktuellen Einträge des Knotens als Belege, neueste zuerst, im Standardumschlag für Listen. Ohne connector_id blättert sie alle Register in der Reihenfolge von records im Knotenabruf, mit connector_id, so wie es die Zeilen in registers tragen, ein einzelnes Register. total ist die genaue Anzahl dessen, was geblättert wird, und jede Seite nennt zusätzlich records_total, die Anzahl des Knotens, und registers, die Anzahl je Register, sodass schon die erste Seite zeigt, welche Register sich zu lesen lohnen.
GET /v1/nodes/{node_id}/financials, die Finanzkennzahlen des Knotens, jede Zeile mit Angabe ihres Quelleintrags. Eine Zeile mit derived gleich true steht so nicht im zitierten Abschluss. Sie wurde aus zwei Zahlen dieses Abschlusses berechnet, und derivation sagt in einfachen Worten, wie. Jede andere Zeile wird so geliefert, wie sie eingereicht wurde.
GET /v1/nodes/{node_id}/sector-context, amtliche deutsche Statistik neben einem deutschen Unternehmen, die Zahlen zu Unternehmensinsolvenzen und Unternehmen, die Destatis für seinen WZ 2008 Abschnitt (sector) und sein Bundesland (regional) veröffentlicht. Jede Zahl trägt ihren table_code, period, retrieved_at, source_url und attribution, den Quellenvermerk, den die Lizenz (dl-de/by-2-0) überall dort verlangt, wo die Zahl gezeigt wird. value ist null, wenn die Tabelle statt einer Zahl ein Zeichen druckt, das dann in value_sign steht. Kein deutsches Register nennt den NACE Code eines Unternehmens, daher benennt nace den Wirtschaftszweig, wenn Sie ihn kennen (nace_source ist dann caller); das Bundesland stammt aus der Registerjurisdiktion oder dem Registergericht. missing nennt in einfachen Sätzen alles, was nicht vorliegt, den Kreis eingeschlossen. Für ein Unternehmen mit Sitz außerhalb Deutschlands ist applies false, missing leer, und note sagt in einem Satz, dass diese deutsche Statistik nicht anwendbar ist. Die Zahlen sind nur Kontext und ändern nie eine Bewertung oder einen Status.
GET /v1/nodes/{node_id}/events, der Feed der Registerereignisse zum Knoten, gruppiert und nach Stufe sortiert, jede Zeile mit Angabe des belegenden Eintrags, soweit einer existiert. group klappt eine Sammelzeile in ihre Einzelzeilen auf. Eine deutsche Insolvenzbekanntmachung erhält ihre tier aus dem veröffentlichten Verfahrensschritt. Eröffnungen, Sicherungsmaßnahmen und Abweisungen mangels Masse sind Zeilen der Stufe alert, spätere Veröffentlichungen im Verfahren Zeilen der Stufe review. Eine deutsche Insolvenzbekanntmachung wird einem Unternehmen nur über das Registergericht und die Registernummer zugeordnet, die sie selbst nennt, nie über einen Namen. Nennt sie einen Registereintrag, den das Unternehmen nicht führt, bleibt sie ihm fern. Ein Ereignis, dessen attrs.history_backfill true ist, wurde aus bereits vorliegender Registerhistorie nachgeladen und nicht am Tag seines Eintreffens veröffentlicht; sein occurred_at bleibt das Datum, das das Register nennt. Bei allen anderen Ereignissen ist das Feld null. Für ein Unternehmen mit deutschem Registereintrag führt der Feed zudem insolvency_lookup, das angibt, wie aktuell seine deutschen Insolvenzbekanntmachungen sind. Sein state ist current, wenn das Unternehmen in der letzten Woche abgefragt wurde, stale, wenn das länger her ist, pending, wenn Ihr Arbeitsbereich eine Abfrage angefordert hat, die noch nicht gelaufen ist, und sonst not_looked_up. Ein Unternehmen, das eine Person Ihres Arbeitsbereichs im Dashboard öffnet, wird innerhalb weniger Minuten abgefragt. Deutsche Insolvenzbekanntmachungen werden nur für ein Unternehmen abgefragt, nach dem eine Person Ihres Arbeitsbereichs gefragt hat, indem sie es im Dashboard geöffnet, in einem Screening geprüft, in ein Dossier aufgenommen oder im Bestand geführt hat, daher ist der state für jedes andere Unternehmen not_requested, und beide Zeitpunkte sind null. Die Abfragen laufen nur für Arbeitsbereiche, in denen sie eingeschaltet sind, daher meldet insolvency_lookup in jedem anderen Arbeitsbereich not_looked_up. Jeder Arbeitsbereich folgt seinem eigenen Zeitplan für die Abfragen, daher ist looked_up_at die letzte Abfrage Ihres eigenen Arbeitsbereichs, nie die eines anderen. looked_up_at und requested_at tragen die Zeitpunkte, note den Satz, der neben dem Feed anzuzeigen ist. Das Portal erlaubt nur Einzelabfragen zu einem Unternehmen, daher sind diese Bekanntmachungen genau so vollständig wie die Abfrage zu looked_up_at. Für jedes andere Unternehmen ist das Feld null, und sein Abruf fordert nie eine Abfrage an. Jede Zeile trägt action, einen festen Satz, der den nächsten eigenen Schritt der Bank für diese Art von Ereignis nennt, eine Entscheidung oder einen Schritt an ihren eigenen Unterlagen.
GET /v1/nodes/{node_id}/energy-emissions liefert den Kontext zu Energie und Emissionen eines Unternehmens. power_plants nennt die Erzeugungseinheiten ab 10 MW, für die die Kraftwerksliste der Bundesnetzagentur das Unternehmen als Betreiber führt, mit Leistung, Energieträger und Status und, wo die Stilllegungsliste der BNetzA eine Einheit nennt, der Kategorie der Stilllegung und dem Zeitraum, den diese Liste nennt (ein Datum je Einheit wird nicht veröffentlicht). reported_emissions nennt die PRTR Betriebe auf thru.de, deren Betreiber oder Muttergesellschaft das Unternehmen ist, jeweils im jüngsten Berichtsjahr mit jeder gemeldeten Freisetzung in Luft, Wasser und Boden und jeder Schadstoffverbringung im Abwasser, die Mengen wie veröffentlicht. macro_context enthält den jüngsten Zinssatz und Kreditbestand der Banken für Unternehmen aus der Statistik der Bundesbank und für einen Kraftwerksbetreiber die Kredite an die Energieversorgung und Wasserversorgung, jeder Wert in value_published genau so, wie die Bundesbank ihn druckt. Ein Betreiber wird dem Unternehmen nur über seine MaStR Betreibernummer oder über seinen exakten Firmennamen mit gesetzlichem Rechtsformzusatz zugeordnet, der genau ein Unternehmen trifft (binding_rule, binding_value), nie über einen ähnlichen Namen. Jeder Wert trägt source_url, retrieved_at und attribution, den Quellenvermerk mit Bereitsteller, Datensatz und Lizenz. missing nennt in einfachen Sätzen, was nicht vorliegt. Die Zahlen sind nur Kontext und ändern nie eine Bewertung oder einen Status.
GET /v1/nodes/{node_id}/regional-context liefert amtliche Regionalstatistik neben einem deutschen Unternehmen. economy enthält die Tabellen der VGR der Länder für seinen Kreis, jeweils die beiden neuesten Jahre, und housing die Zahlen des Zensus 2022 (Stichtag 15. Mai 2022) für seine Gemeinde und seinen Kreis, und indicators die Tabellen des Regionalatlas Deutschland für seinen Kreis (Bevölkerungsbewegung, Gewerbeanmeldungen, Unternehmensinsolvenzen je 10.000 Unternehmen, Arbeitslosigkeit, verfügbares Einkommen), jeweils die beiden neuesten Jahre, labour_market die monatlichen Eckwerte der Bundesagentur für Arbeit für seinen Kreis (Arbeitslose und Unterbeschäftigung ohne Kurzarbeit, die neuesten 13 Monate, sodass neben dem neuesten Monat der Vorjahresmonat steht), und regional_database die Tabellen der Regionaldatenbank Deutschland für seine Gemeinde und seinen Kreis (beantragte Unternehmensinsolvenzen nach Abschnitten der WZ 2008 je Kreis, die Hebesätze der Grundsteuer und der Gewerbesteuer je Gemeinde), jeweils die beiden neuesten Jahre. Jede Zahl trägt ihre table_id, period, retrieved_at, source_url und attribution, den Quellenvermerk, den der Herausgeber überall dort verlangt, wo die Zahl gezeigt wird, und value ist null, wenn die Tabelle statt einer Zahl ein Zeichen druckt, das dann in value_sign steht. status_flag ist p bei einer vorläufigen Zahl, etwa den neuesten drei Monaten der Unterbeschäftigung der Bundesagentur für Arbeit. region sagt, wie das Unternehmen verortet wurde. Der Sitz aus dem Handelsregisterauszug muss genau einem Gemeindenamen der BKG Verwaltungsgebiete VG250 im Land des Unternehmens gleichen. Nennt kein Auszug einen Sitz, wird der Sitz aus der neuesten deutschen Insolvenzbekanntmachung zum Unternehmen ebenso zugeordnet, und zwar im Land des Registergerichts, das diese Bekanntmachung nennt; widerspricht dieses Land der Registerzuständigkeit des Unternehmens, wird nichts zugeordnet. method ist dann insolvency_notice_seat_name, land_basis ist insolvency_notice_register_court, und seat_label lautet etwa seat as stated in the insolvency notice of 14 Sep 2026, nie register seat. Der Quellenvermerk dieser Zuordnung steht in join_layer_attribution. Andernfalls ist determined false, reason nennt den Grund in einem einfachen Satz, und missing nennt alles, was nicht vorliegt. Für ein Unternehmen mit Sitz außerhalb Deutschlands ist applies false, missing leer, und note sagt in einem Satz, dass diese deutschen Quellen nicht anwendbar sind. Die Zahlen sind nur Kontext und ändern nie eine Bewertung oder einen Status.

Jeder Eintrag in records eines Knotens trägt verify_status, das Ergebnis der jüngsten Prüfung dieses Eintrags an seiner Quelle. ok bedeutet, dass die Quelle den Eintrag weiterhin so führt wie gespeichert. gone bedeutet, dass die Quelle ihn nachweislich nicht mehr führt; der Eintrag bleibt zur Prüfung erhalten und wird nie gelöscht. unreadable bedeutet, dass die jüngste Prüfung die Quelle erreicht hat, ihre Antwort aber weder den Eintrag noch sein Fehlen belegt; am Eintrag wurde nichts geändert. Wird sein Knoten beobachtet, prüft jede Aktualisierung der Beobachtung einen solchen Eintrag erneut, täglich oder wöchentlich nach ihrer cadence. Jeder andere solche Eintrag steht in der Warteschlange hinter allen Einträgen, die nicht in diesem Zustand sind, und wird erst dann erneut geprüft, wenn ein Prüflauf nach all diesen noch Kapazität hat. null bedeutet, dass für den Eintrag noch keine Prüfung erfasst ist. Einträge des deutschen Handelsregisters (handelsregister_de) sind davon ausgenommen. Keine planmäßige Prüfung liest sie erneut, ihr verify_status ändert sich daher nur, wenn eine Person das Unternehmen erneut nachschlägt, und ein Eintrag, den eine frühere planmäßige Prüfung auf unreadable gesetzt hat, behält diesen Status bis dahin.

Finanzierung

GET /v1/nodes/{node_id}/financing, die Verschuldungsseite des Knotens, also eingetragene Sicherheiten, notierte Schuldtitel, eingereichte Schuldpositionen und der Abdeckungsstand je Quelle, damit benannt ist, wonach nicht gesucht wurde. unmatched_lines einer Sicherheit nennen im Wortlaut die Sicherungsnehmer, die das Register angibt und die kein Knoten bindet, in Arbeitsbereichen, in denen Personendaten eingeschaltet sind, und sind anderswo leer.
GET /v1/nodes/{node_id}/public-funding, öffentliche Zuschüsse und staatliche Beihilfen, die dem Unternehmen zugeordnet sind (das EU State aid Transparency Award Module, Kohesio und das Financial Transparency System), jede Zuwendung mit Quellenangabe und der Angabe in binding_basis, wie sie zugeordnet wurde (vat, de_register, lei, pic, oder de_register_number für eine Registernummer ohne Registergericht, die nur zusammen mit dem genauen Namen und der Rechtsform zuordnet), mit Summen je Jahr und je Programm, die nie Beträge unterschiedlicher Grundlage oder Währung addieren; eine Spanne, die die Quelle angibt, bleibt eine Spanne. Abdeckung nennt die Hinweise der Kommission zu den Beträgen staatlicher Beihilfen.
GET /v1/nodes/{node_id}/collateral-sites listet die Standorte, die ein Unternehmen betreibt, mit den Koordinaten, die das Marktstammdatenregister für sie angibt, eine Energieeinheit je Zeile mit belegtem Datensatz, seitenweise. total zählt die Standorte, deren Koordinaten Zahlen innerhalb Deutschlands sind, with_coordinates jede Einheit, die beide angibt. Nichts wird geokodiert.

Netz

GET /v1/nodes/{node_id}/network liefert das Registerumfeld des Knotens, seine Organe, Gesellschafter und wirtschaftlich Berechtigten, seine Beteiligungen, Zweigniederlassungen und anderen Registerbeziehungen. nodes enthält den Knoten und seine Nachbarn in der Knotenform oben, und jeder Eintrag von edges nennt edge_type, role, pct, wo das Register einen Anteil angibt, valid_from, valid_to und current und trägt citation, den Registereintrag, der ihn belegt, mit source_url und retrieved_at. Aktuelle Kanten stehen vor beendeten. edge_types behält nur die genannten Arten, zum Beispiel officer_of,owns, und limit begrenzt die Nachbarn auf höchstens 200, wobei truncated sagt, ob gekürzt wurde. Natürliche Personen und ihre Kanten werden in Arbeitsbereichen ausgeliefert, in denen Personendaten eingeschaltet sind, und anderswo weggelassen. Das Lesen des Netzes stößt nie eine Registerabfrage an.

Beteiligungsverhältnisse

GET /v1/nodes/{node_id}/ownership-chain liefert die Eigentümerketten des Knotens nach oben, Schritt für Schritt, jeder Schritt belegt. In einem Arbeitsbereich, in dem Personendaten eingeschaltet sind, werden natürliche Personen als Eigentümer mit ihren Belegen genannt. Anderswo endet eine Kette, die eine Person erreicht, dort mit einem ausdrücklich gesperrten Endknoten. params.include_persons sagt, was galt.

Registerbeobachtungen

GET /v1/watches, die Registerbeobachtungen Ihres Arbeitsbereichs, neueste zuerst, die Unternehmensknoten und, wo Personendaten eingeschaltet sind, die Personenknoten, deren Registerdaten er aktuell hält. Eine Registerbeobachtung bewertet nichts; das Kreditmonitoring ist das Portfolio oben.

Benachrichtigungen

GET /v1/alerts/events, die Meldungen Ihres Arbeitsbereichs, neueste zuerst, jede mit ihrer event_class (risk_red, risk_amber, insolvency_notice, sanctions_candidate, tender_match, press_candidate oder monitoring_finding), ihrem severity (critical, high oder info), team_id (null für den ganzen Arbeitsbereich, etwa bei einem beobachteten Unternehmen), node_id und exposure_id ihres Gegenstands, der source, auf der sie beruht (kind und id), occurred_at und created_at. Eine Meldung nennt nur Kennungen, nie einen Namen. Filterbar nach event_class und severity. Eine natürliche Person, die Ihr Arbeitsbereich beobachtet, meldet sich wie ein Unternehmen, wo Personendaten eingeschaltet sind. Dieser Abruf hält die Meldungen risk_red und risk_amber eines Einzelunternehmens zurück, und ein Abruf, der eine Meldung zu einer Person oder zum Unternehmen eines Einzelunternehmers ausliefert, schreibt den Eintrag ins Protokoll der Personenzugriffe.
GET /v1/alerts/deliveries, das Zustellprotokoll jedes Kanals, neueste zuerst. Jeder Versuch hat eine Zeile für die Übernahme (queued, oder held_budget oder held_quiet, wenn er nicht gesendet wurde, digest, wenn die Tatsache für eine sofortige Meldung zu alt ankam) und eine Zeile für das Ergebnis (sent, oder failed mit seiner error_class), und eine Zustellung endet in höchstens einer Zeile delivered (Ihr Empfänger hat einen signierten Webhook bestätigt, oder der SMS Anbieter hat die Zustellung gemeldet), einer Zeile undelivered (der abschließende Bericht des SMS Anbieters, dass sie nicht zugestellt wurde) oder einer Zeile dead_letter (ein dauerhafter Fehler, oder alle Wiederholungen verbraucht). Jede Zeile nennt ihre Meldung über event_id und einen Endpunkt über endpoint_id (null bei der eigenen Mail, SMS oder dem Eintrag im Dashboard eines Mitglieds); die Identität einer Person wird nicht ausgeliefert. Filterbar nach event_id, status und channel. Das Protokoll listet nur die Zustellungen der Meldungen, die GET /v1/alerts/events Ihnen ausliefert, sodass jede event_id eine Meldung dieser Liste nennt, und die event_id einer Meldung, die jener Abruf zurückhält, antwortet wie eine unbekannte.

Ein Schlüssel liest die Meldungen seines eigenen Teams und ihre Zustellungen, dazu jene für den ganzen Arbeitsbereich; angemeldete Administratoren und Compliance Beauftragte lesen alle Teams. Die Kanäle selbst werden hier nicht gelistet. Sie werden nur im Dashboard angelegt, getestet und deaktiviert, und keine Adresse, keine Nummer und kein Schlüssel wird ausgeliefert. Siehe Benachrichtigungen über Teams und Webhook und Benachrichtigungen per SMS.

Nachrichtenbeobachtung

GET /v1/news/companies, die Unternehmen aus Bestand und Beobachtungsliste Ihres Arbeitsbereichs und die Personen, die er beobachtet (node_type person), jedes mit seiner neuesten täglichen Tonlage eines vollständig gelesenen Tages, seitenweise mit limit und offset. Ein Unternehmen ohne gespeicherte Tonlage antwortet mit latest null, was nichts über seine Berichterstattung sagt.
GET /v1/news/companies/{node_id}, die täglichen Tonlagen eines Unternehmens, neueste zuerst (days, 30, wenn nichts angegeben ist, höchstens 90), und die neuesten 100 Artikel hinter der neuesten samt jedem Artikel, den seine Ereignisse nennen. Der state einer Tonlage ist reading, too_little_coverage oder feed_gap, nur reading trägt tone_mean, und article_keys belegen die neuesten 100 der Artikel, auf denen sie beruht, während articles_window sie alle zählt. Jeder Artikel trägt seinen article_key, url, publisher_host, published_at, language, gdelt_tone und matched_organization, und jede Antwort trägt die attribution von GDELT, die mit den Daten zu zeigen ist. events listet die ernsten Nachrichtenereignisse des Unternehmens aus denselben Tagen, jedes mit event_type, severity, Daten, articles, sources, languages, ob es eine Meldung ausgelöst hat (alerted), den article_keys seiner neuesten 20 Artikel und seiner Nachrichtenprüfung check (status, verdict, die bestätigte event_type und severity, der zitierte article_key, reason, model, prompt_version, checked_at und second_source_articles, die Artikel aus NewsAPI.ai, die die Prüfung gelesen hat, mit Link, Herausgeber, Datum und Sprache), und nur ein Ereignis mit confirmed meldet sich; ein Team liest die Ereignisse seines eigenen Teams und jene für den ganzen Arbeitsbereich. Eine Person wird wie ein Unternehmen gelesen und nie bewertet. Ein Einzelunternehmen (sole_trader true) wird nie bewertet und trägt keine Tonlage, es antwortet daher mit latest null, ohne readings und mit seinen Artikeln mit gdelt_tone null, während seine Nachrichtenereignisse ausgeliefert werden.

Ein Schlüssel liest die Unternehmen aus dem Bestand seines eigenen Teams und die Unternehmen, die sein Arbeitsbereich beobachtet; jedes andere Unternehmen antwortet mit 404. Siehe Nachrichtenbeobachtung.

Beobachtung sozialer Medien

Ausgeschaltet, bis eine lizenzierte Quelle für soziale Medien für Ihren Arbeitsbereich eingeschaltet ist. Jede Antwort sagt das in source.enabled, und solange es false ist, wird keine Lesung und kein Beitrag gezeigt.

GET /v1/social/companies, die Unternehmen aus Bestand und Beobachtungsliste Ihres Arbeitsbereichs und die Personen, die er beobachtet (node_type person), jedes mit seiner neuesten täglichen Lesung sozialer Medien eines vollständig gelesenen Tages, seitenweise mit limit und offset. Ein Unternehmen ohne gespeicherte Lesung antwortet mit latest null, was nichts über seine Abdeckung sagt.
GET /v1/social/companies/{node_id}, die täglichen Lesungen eines Unternehmens, neueste zuerst (days, 30, wenn nichts angegeben ist, höchstens 90), und seine neuesten 100 Beiträge der letzten 30 Tage. Der state einer Lesung ist reading, too_little_coverage oder feed_gap, nur reading trägt sentiment_net, und sie zählt ihre Beiträge in platform_counts, positive, negative, neutral und unrated, während item_keys die neuesten 100 davon belegen. Jeder Beitrag trägt seinen item_key, platform, url (null mit link_withheld true, wenn die Adresse des Links die eigene Seite oder das Handle einer Person erkennen lässt), published_at, language, sentiment und matched_name, aber keinen Verfasser, kein Handle, keinen Titel und keinen Text. Ein Einzelunternehmen (sole_trader true) hat keine Lesung, latest null, und seine Beiträge tragen sentiment null.

Screenings

GET /v1/screenings, die Läufe des Screenings auf Negativpresse Ihres Arbeitsbereichs über Organisationen und Länder, neueste zuerst, und über natürliche Personen in Arbeitsbereichen, in denen Personendaten eingeschaltet sind. Die Filter sind entity_id, node_id, iso3, subject (der Name des geprüften Subjekts, abgeglichen über seine normalisierte Form) und subject_type (entity, country oder person). Ein Screening von Personen wird nur mit seinen belegten Feststellungen und deren Quellen ausgeliefert, in der Einzelansicht daneben mit dem Abgleich gegen die offiziellen Listen, und mit nichts sonst. Es trägt keine Einstufung (worst_verdict ist null), keine Bewertungen, keine entworfene Zusammenfassung und keinen Score. Wo Personendaten ausgeschaltet sind, beantwortet der Filter person eine leere Seite und die Kennung eines Screenings von Personen eine 404.
GET /v1/screenings/{screening_id}, ein Screening mit seinen Einschätzungen je Kategorie, seinen Feststellungen und den belegten Pressezitaten. Die rationale jeder Einschätzung ist maschinell verfasst, und jedes [f<id>] darin nennt eine der finding_ids der Einschätzung und belegt den Eintrag in findings mit dieser finding_id. findings enthält nur belegte Feststellungen, daher hat eine zitierte Feststellung, die die Prüfung als unverifiziert herabgestuft hat (sie hatte kein wörtliches Zitat zum Anzeigen), dort keinen Eintrag. rationale_withheld zählt die Sätze, die zurückgehalten wurden, weil sie nicht mit ihren Belegen angezeigt werden konnten. Zwei Prüfungen laufen über diesen Text. Wenn sich zwei Einschätzungen darin widersprechen, ob das Subjekt selbst in einer Sache angeklagt, mit einer Geldbuße oder Strafe belegt oder verurteilt wurde, werden beide Aussagen zurückgehalten, eine rationale trägt einen Satz, der mit "Conflicting evidence" beginnt und die Feststellungen belegt, und die andere verweist darauf. Ein Satz, der sich nur auf Feststellungen stützt, deren eigener Text das Ereignis vor window_years datiert, wird zurückgehalten, und ein Satz in derselben rationale nennt diese Feststellungen und ihre Jahre.
GET /v1/deals/{deal_id}/screening-rollup, das Screeningbild über die Beteiligten einer Transaktion hinweg.
official_lists in GET /v1/screenings/{screening_id} ist der Abschnitt Offizielle Listen, der erste Teil jedes Screeningergebnisses. Er ist ein deterministischer Abgleich des Subjekts mit jeder in lists genannten offiziellen Sanktionsliste, ohne Suche und ohne Modellaufruf. Der Abgleich erfolgt beim Lesen des Ergebnisses, zum Zeitpunkt as_of, und nicht am Tag des Screenings. Jede Liste trägt genau einen status. listed bedeutet, dass ein Eintrag eine Kennung trägt, die die Liste selbst nennt und die auch der eigene Registereintrag des Subjekts trägt, etwa einen LEI, einen BIC oder eine Registernummer. Der Registereintrag ist der eigene des Subjekts, wenn ein Analyst ihn ausgewählt hat. Wurde er dem Subjekt über den Namen zugeordnet, erscheint ein Kennungstreffer als Namensübereinstimmung zur Prüfung, mit einem note, der das sagt. name_match_awaiting_review bedeutet, dass ein Eintrag nur den Namen mit dem Subjekt teilt. Das ist ein Kandidat zur Prüfung und niemals ein Treffer, und fields stellt Eintrag und Subjekt nebeneinander, jede Zeile same, differs oder not_stated. Namen werden exakt über einen normalisierten Schlüssel abgeglichen, andere Schreibweisen, Wortfolgen und Transliterationen werden daher nicht gefunden. name_match_reviewed bedeutet, dass eine prüfende Person jede Namensübereinstimmung als same_party oder different_party abgeschlossen hat, was aus einem Namen nie eine Listung macht. no_entry_found kommt mit edition und checked_at der Liste und mit compared, dem Satz, der sagt, was verglichen wurde. not_checked kommt mit einem reason, zum Beispiel bei einer abgeschalteten Liste oder einer Liste, deren letzte Prüfung mehr als 48 Stunden zurückliegt, und liest sich nie als unbedenklich. counts nennt, wie viele Listen welchen Status tragen, und lists_compared, wie viele Listen eingeschaltet waren und innerhalb von 48 Stunden geprüft wurden. Ein Eintrag zu einer Organisation, einem Schiff oder einem Luftfahrzeug trägt außerdem published_fields, jedes Feld, das die Liste zu diesem Eintrag veröffentlicht, in der Reihenfolge der Liste, jeweils mit path, der Stelle im Eintrag, an der die Liste es nennt, in den Elementnamen und Attributnamen der Liste selbst, und value, wörtlich. Dazu gehören Anschriften und Kontaktangaben, die Begründung und die Anmerkungen, die Daten des Listungsrechtsakts, der Verweis auf die Liste der Vereinten Nationen und die Muttergesellschaften und Tochtergesellschaften, die eine Liste nennt. Sie sind Angaben der Liste neben dem Ergebnis und ändern nie einen Status. Die Feldfamilien, die eine natürliche Person nennen können, der Freitext (Anmerkungen, Begründungen, sonstige Angaben, Funktionen und Titel), andere Parteien (Muttergesellschaften und Tochtergesellschaften, Eigner und Betreiber), Kontaktangaben, Ausweisdokumente und persönliche Steuernummern sowie eine Anschrift, deren Zeile jemanden zu Händen oder mit einer Anrede nennt, werden nur in Arbeitsbereichen ausgeliefert, in denen Personendaten eingeschaltet sind. Anderswo werden sie zurückgehalten, und der Eintrag trägt dann published_note, einen Satz, der sagt, dass weitere Angaben nach den Bedingungen des Arbeitsbereichs für Personendaten zurückgehalten sind; sonst ist published_note null. Ein Land wird mit diesen Listen nicht abgeglichen. Der Abschnitt ersetzt nicht Ihre eigene Prüfung auf Sanktionen und politisch exponierte Personen.

Abgleich von Personen mit Sanktionslisten

GET /v1/sanctions/person-candidates führt die Prüfkandidaten für die natürlichen Personen, die öffentliche Register mit den Unternehmen im Bestand Ihres Teams verbinden, dem Namen nach und über die Aliasnamen der Liste selbst abgeglichen mit den natürlichen Personen auf den sechs amtlichen Sanktionslisten, den EU Financial Sanctions Files, der UK Sanctions List, den beiden Listen des OFAC (SDN und ohne SDN), der Schweizer Sanktionsliste des SECO und der Konsolidierten Liste des Sicherheitsrats der Vereinten Nationen. Ein Geburtsdatum oder eine Staatsangehörigkeit, die beide Seiten nennen und die sich widersprechen, schließt ein Paar aus. Jeder Eintrag nennt sein Team, die Person aus dem Register (node_id, node_label) und die Unternehmen, mit denen sie verbunden ist (linked), die Liste (list_name), die Listungsnummer (designation_ref), die gelisteten Namen, das Datum der Listung, sofern die Liste eines nennt, was übereinstimmt (matched_on, name oder alias) und was eingegrenzt hat (narrowed_on, date_of_birth oder nationality), sowie die amtliche Datei (official_url). Kein Geburtsdatum und keine Staatsangehörigkeit der Liste wird ausgeliefert. status ist open oder confirmed, sobald eine Analystin oder ein Analyst den Treffer im Dashboard bestätigt hat, wo die Entscheidungen fallen. Ein Kandidat setzt nie einen Portfoliostatus oder einen Score und zählt nie als Treffer, und ein zurückgewiesener Kandidat erscheint erst wieder, wenn die Liste ihren Eintrag ändert. Offene Kandidaten stehen vorn. Die Seite trägt außerdem lists, einen Eintrag für jede der sechs Listen mit ihrem list_name, ihrer Lesart reading (Checked oder Not checked), dem Grund reason, wenn sie nicht geprüft ist, dem Stand des Herausgebers in edition und published_on und dem Zeitpunkt der letzten Prüfung in checked_at, dazu lists_not_checked, deren Anzahl, und persons_compared, die Anzahl der abgeglichenen Registerpersonen. Eine Liste, die ausgeschaltet ist oder in den letzten 48 Stunden nicht geprüft wurde, liest sich als Not checked, daher sagt eine leere Seite nur, dass es unter den abgeglichenen Registerpersonen keinen offenen oder bestätigten Kandidaten gibt, und sie sagt nichts, solange lists_not_checked größer als 0 ist. Verworfene Kandidaten werden nicht ausgeliefert, und eine Person, die kein angebundenes Register mit Ihrem Bestand verbindet, wird nicht abgeglichen. Die Route antwortet in den Arbeitsbereichen, in denen Personendaten eingeschaltet sind, nie in der Sandbox, und sonst mit dem kanonischen 404.

Ausschreibungen

GET /v1/tenders/profiles listet die aktiven Suchprofile Ihres Teams nach Namen, jedes mit dem, was es von einer Bekanntmachung verlangt (cpv_codes, nuts_codes, value_min_eur, value_max_eur, procedure_types, buyer_legal_types, form_types, deadline_min_days, keywords), seinem Zweck use_case und ob es active ist. Eine leere Liste oder eine fehlende Grenze ist ein Kriterium, das das Profil nicht setzt. Wer ein Profil angelegt hat, wird hier nicht ausgeliefert.
GET /v1/tenders/matches listet die Treffer Ihres Teams, neueste zuerst, einer je Vergabeverfahren und Profil. status (new, dismissed oder in_deal_book) und profile_id grenzen die Liste ein. Jeder Treffer enthält reasons, einen Eintrag je Kriterium seines Profils mit outcome, reason, dem gelesenen Feld field der Bekanntmachung, dem, was sie dort nennt (stated), was das Profil verlangt (wanted) und was getroffen hat (matched), und notice, die zitierte Bekanntmachung mit source_url und record_id. Eine Bekanntmachung ist nur dann ein Treffer, wenn jedes Kriterium trifft. Kein Treffer liefert die Zuschlagsempfänger aus, und ein Auftraggeber, dessen genannte Rechtsform eine natürliche Person bezeichnen kann, wird zurückgehalten (buyer_withheld). Ein Treffer kann stattdessen eine Bekanntmachung aus dem eigenen Portalbereich Ihres Teams in portal_notice zitieren, mit notice null, einen Export, den Ihre Bank hochgeladen hat, oder eine Benachrichtigung eines ihrer Portalzugänge (arrived nennt, welches), und decided_by sagt, ob ein Suchprofil oder der Suchagent des Portals selbst ihn ausgewählt hat (portal_search, mit profile_id null). Kein Portalzugang, keine Adresse und kein Schlüssel wird ausgeliefert. Siehe Suchprofile und Treffer für Ausschreibungen.
GET /v1/tenders/matches/{match_id} liest einen Treffer Ihres Teams. Wer einen Treffer verworfen hat, wird hier nicht ausgeliefert.
GET /v1/tenders/deals/{deal_id} listet die Treffer Ihres Teams, die eine Analystin oder ein Analyst in diesen Deal des Deal Book übernommen hat, neueste zuerst, jeden so, wie GET /v1/tenders/matches ihn liefert. Ein Deal eines anderen Teams oder einer ohne Treffer ergibt eine leere Liste. Siehe Suchprofile und Treffer für Ausschreibungen.
POST /v1/tenders/portals/upload zeigt die Vorschau eines Uploads aus einem Vergabeportal. Der Body trägt den Dateinamen in file_name, das Portal, aus dem sie exportiert wurde, in source_portal, die CSV, XLSX oder eForms XML Datei base64 kodiert in content_base64 (höchstens 700.000 Bytes) und auf Wunsch mapping, ein Objekt von Spaltenname zu Feld. Jede Zeile wird mit ihrem Ergebnis für den eigenen Ausschreibungsbereich Ihres Teams und dem Grund beantwortet, die Zeilen kommen seitenweise über limit (höchstens 100) und offset, während counts, counters und total die ganze Datei umfassen. Eine Kopfzeile, die kein Portalprofil erkennt, beantwortet mapping_required mit den columns der Datei. dry_run ist hier immer true, es wird also nichts geschrieben, und bestätigt wird ein Upload im Dashboard. Ein Upload aus einem Portal, dessen Uploads vorerst nicht angenommen werden, wird mit einem 422 abgelehnt, das den Grund nennt. Dateien, Felder, Portale und Ergebnisse beschreibt Exporte aus Vergabeportalen.

Lizenzierte Daten

GET /v1/licensed-data/facts listet die Werte zu Unternehmen, die ein von Ihrer Bank lizenzierter Datenanbieter genannt hat (North Data), abgerufen mit dem eigenen Schlüssel Ihrer Bank in Ihren Arbeitsbereich, mit name, stated_legal_form, register_value, register_status, lei, wo genannt, node_id, wenn eine genannte Kennung ein Unternehmen des Graphen bindet, source_url (die eigene Seite des Anbieters), provider_updated_at und retrieved_at. Ausgeliefert werden nur Werte, die unter dem Lizenzumfang internal_systems abgerufen wurden, der die eigenen Systeme Ihrer Bank abdeckt, und die Beispieldaten des Demonstrationsarbeitsbereichs. node_id und register (eine deutsche Registernummer mit Gericht) grenzen die Liste ein, seitenweise über limit und offset. Angebunden und abgerufen wird im Dashboard, und kein Schlüssel und keine Anbindung wird ausgeliefert. Siehe Eigene Quellen.

Transaktionen

GET /v1/deals, das sortierte Deal Book. Es filtert nach stage, window, country_code, region, sector, status, eca, eca_named, min_value_usd und q. q und eca finden ihren Text so, wie er geschrieben ist, % und _ sind also keine Platzhalter. q behält die Deals, deren Name, Zusammenfassung oder Käufer den Text enthält oder bei denen ein Name einer Agentur oder eines Exporteurs ihn enthält, und eca die Deals, bei denen ein Name einer Agentur ihn enthält. Eine Agentur wird unter dem Namen gefunden, den die Zeile in ecas und agencies führt, unter den anderen Namen, die das Verzeichnis für sie führt (full_name und aliases in GET /v1/entities), und unter dem Namen, den die Quelle gemeldet hat. sort ist standardmäßig priority, zuerst das Fenster und darin der Score. score, value, last_activity, stage, name und first_seen ordnen jeweils das ganze gefilterte Buch nach dieser einen Spalte, value nach dem Wert in USD aus contract_value_usd, last_activity nach last_event_at und stage nach der Reihenfolge der Phasen jedes Desks in seiner Pipeline. latest_update ordnet allein nach dem neuesten datierten Ereignis, das neueste zuerst, die Zeilen ohne ein solches zuletzt, bei Gleichstand nach dem Score. direction ist standardmäßig desc oder asc, und die Prioritätsordnung und latest_update gibt es nur als desc. Zeilen ohne Wert stehen in beiden Richtungen am Ende, und bei Gleichstand entscheidet deal_id. Ein unbekannter Wert für sort oder direction wird mit 422 abgelehnt. Jede Zeile führt agencies, eine je Institution unter ihrem kanonischen Verzeichnisnamen, mit ihrer Art kind (eca, multilateral, dfi, development_bank, agency oder bank), kind_label und roles (agency, dazu lender, wenn die Kreditgeberliste sie ebenfalls nennt); kind ist null, wenn das Verzeichnis die gemeldete Schreibweise nicht führt, und eca_named behält genau die Deals, deren agencies eine Institution der Art eca führen. Die Zeilen, die ein Desk standardmäßig zurückhält (score_hidden gleich true, also Finanzierung steht, abgebrochen, älter als das Veraltungsfenster von standardmäßig 12 Monaten, ohne Bewegung seit 12 Monaten, in einem Markt außerhalb eines Immobilienmandats, eigene Bank, inländisch oder unter der Wertschwelle des Teams), erscheinen nur mit include_hidden=true. Die Seite führt stale_months und movement_months, die beiden Altersregeln in Monaten, wie die Einordnung sie angewandt hat (0, wo eine Regel aus ist; über mehrere Teams hinweg die kürzeste Bewegungsfrist eines dieser Teams), damit sich benennen lässt, warum eine Zeile zurückgehalten wurde.
GET /v1/deals/{deal_id}, eine Transaktion mit ihren Beteiligten, ihrer Zusammenfassung und der belegten Zeitleiste. summary_lines enthält drei Zeilen, nach festen Regeln aus den belegten Feststellungen erzeugt, nicht von einem Modell (wer und was, der von einer Quelle bestätigte Stand, warum es für die Bank zählt), jede mit citations, die das Feld, die verknüpfte Feststellung und das wörtliche Zitat dahinter nennen, und eine Zeile nennt ein Feld nur dann von keiner Quelle bestätigt, wenn kein verifiziertes Zitat es nennt; beim Beleg des gespeicherten Mandatsgrunds aus dem Ranking ist finding_id null. next_action ist nur der eigene Schritt Ihrer Analystinnen und Analysten. timeline_limit deckelt die Zeilen der Zeitleiste, bis 200.
merged_into nennt bei einer Transaktion diejenige, in die sie eingegliedert wurde, nachdem sich beide als dieselbe Transaktion erwiesen haben. Bei jeder eigenständigen Transaktion ist das Feld null; ist es gesetzt, lesen Sie die genannte Transaktion und behandeln Sie diese Zeile als Historie. Eingegliederte Zeilen behalten Zeitleiste und Ereignisse und gelten als verworfen, erscheinen also nur, wenn status verworfene Transaktionen anfordert.
briefing in GET /v1/deals/{deal_id} ist null oder ein Objekt mit text, drafted_at, drafted_by und sources. drafted_by lautet model, weil ein Sprachmodell den Text als kurze Zusammenfassung dessen verfasst, was die belegten Quellen der Transaktion berichten, und sources nennt die Quellen, die es erhalten hat, jede mit source_id, url, publisher und published_at, wobei source_id einem Eintrag der sources der Transaktion entspricht. Es ist keine Tatsachenaussage von Stonewake. Geprüft werden allein seine in Ziffern geschriebenen Zahlen, gegen den Text dieser Quellen, und ein Satz mit einer Zahl, die dort nicht steht, entfällt. Ein Satzteil, der den Leser auffordert, etwas zu bestätigen, zu verifizieren, zu prüfen oder durchzusehen, wird beim Abruf aus text entfernt. briefing ist null, bevor ein Briefing entworfen wurde, solange Briefings ausgeschaltet sind, nachdem sich die Quellen der Transaktion geändert haben, wenn kein Satz die Prüfung bestanden hat und wenn nichts außer einem solchen Satzteil übrig blieb; lesen Sie deshalb summary_lines, wann immer es null ist.
GET /v1/deals/parties/binding-queue listet die Beteiligten an den laufenden Transaktionen Ihres Teams, die noch keinem Unternehmen in einem Register zugeordnet sind, die Liste, die das Dashboard unter Beteiligte einem Register zuordnen zeigt. Zuerst kommen gemerkte Transaktionen, dann die Beteiligten, die markiert sind, weil die von einer Person eingegebene Kennung zwei oder mehr Unternehmen gehört, dann die Beteiligten mit Kandidaten. Jede Zeile nennt ihre Transaktion (deal_id, deal_name, deal_followed), ihr Team (team_id, team_name), role und name der Beteiligten, flagged mit dieser Kennung in flagged_identifier, dismissed, wenn eine Person bereits entschieden hat, dass keiner der Kandidaten passt, und candidates, jeweils ein Unternehmen mit node_id, label, country_iso3 und bis zu drei identifiers, der LEI zuerst. deal_id beschränkt die Liste auf eine Transaktion, und eine Transaktion außerhalb Ihres Teams ergibt eine leere Seite. Die Zuordnung selbst erfolgt im Dashboard.
GET /v1/deals/merge/suggestions ist abgekündigt und antwortet jedem Aufrufer mit einer leeren Seite, total 0 und keinen items. Stonewake findet und bereinigt doppelte Transaktionen selbst, es gibt also keine Dublettenfrage, die Sie lesen oder beantworten müssten. Die Route bleibt bestehen, damit bestehende Integrationen weiter funktionieren, und trägt im OpenAPI Dokument deprecated: true.

Jede Zeile im Deal Book trägt, wie sie eingeordnet wurde. score_window ist das Fenster, in das sie einsortiert wurde, score_window_label das Wort, das eine Leserin sieht, also Finanzierung offen, frühe Phase, nicht bestätigt, Finanzierung steht, abgebrochen. Der Score ist eine Priorität INNERHALB dieses Fensters, nie über das ganze Buch hinweg. Beide werden zusammen gelesen. Eine abgeschlossene Transaktion mit 90 und eine offene mit 60 sind keine vergleichbaren Zahlen, und die Prioritätsordnung stellt die abgeschlossene nie über die offene. score_band ist das Bandwort zur Zahl (das Deal Book zeigt es, wenn Sie auf den Score zeigen), score_reason_count die Anzahl der Begründungen dahinter, und score_hidden markiert die Portfoliozeilen, die ein Desk standardmäßig zurückhält (Finanzierung steht, abgebrochen, älter als das Veraltungsfenster, ohne Bewegung seit 12 Monaten, in einem Markt außerhalb eines Immobilienmandats, eigene Bank, inländisch oder unter der Wertschwelle des Teams; eine veraltete Zeile nennt ihr Datum in den Abwertungen, "Event 1 Mar 2023, over 12 months old"). score_own_bank markiert die Zeilen, in denen die eigene Bank als Kreditgeber genannt ist, gelesen aus der gespeicherten Abwertung; das Deal Book zeigt Your bank is in, wenn Sie auf die erste Partei einer solchen Zeile zeigen. Die Einzelantwort ergänzt score_reasons, also das Bandwort, das Fenster, pro Bewertungskomponente einen Satz in Klartext, welcher Fakt gegriffen hat, die angewandten Abwertungen, jede eine kurze Wendung wie Country not stated, Own bank lends oder No movement since 1 Apr 2025, und lowered, wahr, wenn eine davon den Score senkt. Eine vor dem 20. Oktober 2026 eingeordnete Zeile liefert dieselben kurzen Wendungen. Der Satz zur Beweislage einer Zeile, die die Bestätigungsregel nicht als bestätigt wertet, nennt, wie viele verschiedene Seiten sie belegen, zum Beispiel Cited by 3 pages, no independent second witness, und eine einzelne Seite liest sich als One source reports it, with no second witness.

Jede Zeile trägt außerdem, was die Oberflächen aus ihren gespeicherten Fakten ableiten, damit ein Client dieselben Wörter liest, die das Dashboard, das PDF und die Arbeitsmappe zeigen. state und state_label sind der über die verknüpften Feststellungen bestätigte Stand der Transaktion und sein Wort (frühe Nachricht, geplant, Ausschreibung offen, Auftrag vergeben, Arrangeur mandatiert, Finanzierung wird arrangiert, Deckung dem Grunde nach, Deckung zugesagt, unterzeichnet oder abgeschlossen, abgebrochen, nicht bestätigt); null bedeutet, dass das Zitat keiner Quelle einen Stand bestätigt hat. Eine Interessenbekundung ist ein eigener Stand und nie eine Deckung dem Grunde nach; ihr Wort ist Interessenbekundung, unverbindlich, und ein Schreiben, das älter als 12 Monate ist und nach dem kein späteres Ereignis gemeldet wurde, liest sich als Interessenbekundung, möglicherweise erloschen und steht im Fenster Nicht bestätigt, unter jeder bestätigten Zeile. Eine Transaktion, deren Feststellungen einen Abschluss bestätigen, liest sich als abgeschlossen, es sei denn, eine später datierte Feststellung bestätigt, dass die Finanzierung noch offen ist (eine Interessenbekundung, ein mandatierter Arrangeur, eine Finanzierung, die arrangiert wird, oder eine Deckung dem Grunde nach). event_date ist das neueste Ereignisdatum, das eine Quelle in eigenen Worten genannt hat, nie später als ihre Veröffentlichung und, wo kein Veröffentlichungsdatum bekannt ist, nie in der Zukunft; für eine Interessenbekundung ist es das Datum des ersten Schreibens, das früheste, das eine Quelle genannt hat, oder der Tag, an dem der erste Bericht darüber veröffentlicht wurde, wenn dieser Bericht aus einem früheren Monat stammt oder keine Quelle ein Datum genannt hat, sodass eine Verlängerung ein altes Schreiben nie neu aussehen lässt. null bedeutet, dass keines genannt wurde, und dann gilt last_event_at, das früheste Veröffentlichungsdatum unter den abgerufenen Seiten des neuesten gemeldeten Ereignisses der Transaktion, wobei eine abgerufene Seite einer Primärquelle dieses Ereignis vor den übrigen Seiten datiert. Ein Suchergebnisauszug datiert nie eine Zeile, last_event_at ist null, wenn keine abgerufene Seite datiert ist, und weder event_date noch last_event_at ist je später als der aktuelle Tag in UTC. buyer ist immer einer der Käufer unter den Beteiligten der Transaktion, der bisher genannte, solange die Beteiligten ihn noch nennen, sonst der zuerst erfasste, und contract_value_raw ist ein gemeldeter Betrag mit Währung oder null, nie ein Datum, eine Laufzeit oder eine Kapazität. Wo eine Quelle die Finanzierung nennt, ist er der Finanzierungsbetrag, die Zahl, die die neueste belegte Feststellung neben einem Wort für Schuld oder Deckung nennt, etwa Kredit, Fazilität, Garantie oder Deckung, und eine Zahl, die zwei Websites nennen, geht einer Zahl vor, die nur eine Website nennt; wo keine es tut, tritt ein Auftragswert an seine Stelle, und wo kein Zitat sagt, was die Zahl ist, bleibt der zuerst gemeldete Wert. value_basis sagt, welcher der drei es ist (financing, contract oder unclassified), und ist genau dann null, wenn value_text es ist. Ein Teil eines Pakets, Projektkosten oder ein Programmvolumen sind nie der Wert, und contract_value_finding_id nennt die Feststellung, aus der der Wert stammt. lenders führt die Namen der Kreditgeber der Transaktion in Namensreihenfolge, die dritte Beteiligtengruppe, die die Spalte Parties neben den Agenturen und den Exporteuren zeigt, jede Institution, die das Verzeichnis führt, unter ihrem kanonischen Namen; eine Institution, die agencies schon führt, erscheint hier nicht noch einmal, und ihre roles dort nennen beide Rollen. angle sagt, warum die Zeile auf der Liste des Desks steht (eine Exportkreditagentur genannt, ein Exporteur genannt, ein Käufer genannt oder noch niemand), und ask, was noch zu finanzieren ist, beides in den Worten des Desks des Teams, in dessen Buch die Zeile steht, wer auch immer sie liest (eine Projektfinanzierungszeile nennt DFIs oder ECAs und Sponsoren, eine Immobilienzeile öffentliche Kreditgeber, Investoren und Käufer), abgeleitet aus bestätigtem Stand, Fenster, den genannten Agenturen und den genannten Kreditgebern (ein genannter Kreditgeber ohne Agentur in einer frühen Phase liest sich auf einer Exportfinanzierungszeile als Lenders named, cover open). Eine Zeile, deren Stand keine Quelle bestätigt hat, liest sich als State not confirmed by a source yet, sodass ask nie einen Schritt oder eine offene Rolle nennt, die kein Zitat getragen hat. Einträge der Zeitleiste tragen state, state_label, state_quote (die Passage, die den Stand bestätigt hat, gedeckelt wie jedes Zitat) und event_date, jeweils null, wo nichts bestätigt wurde.

Jede Zeile trägt ihren Wert, einmal entschieden für die Zusammenfassung, die Berichte und jeden Client, der ihn druckt. value_text ist der Betrag in der Währung, in der die Quelle ihn gemeldet hat, und contract_value_usd dient nur als Sortierschlüssel, nie als Zahl zum Anzeigen. value_status ist confirmed, wo ein verifiziertes Zitat die Zahl nennt, und value_text trägt dann das begrenzende Wort, das die Zitate vor die Zahl setzen, etwa up to; value_finding_id nennt die verknüpfte Feststellung, deren Zitat sie nennt. Er ist reported, wo kein verifiziertes Zitat die Zahl bestätigt, und value_note enthält dann den einen Satz, den jede Oberfläche daneben druckt und den die Zusammenfassung wortgleich druckt. Er ist absent, wo kein Betrag gemeldet ist.

Jede Zeile trägt außerdem ihre letzte Aktualisierung. latest_update ist das neueste Ereignis der Zeitleiste der Transaktion, das eine Quelle in eigenen Worten datiert hat und dessen Zitat einen Stand bestätigt hat, oder null, wenn es keines gibt. Sein date ist dieses Ereignisdatum, sein label nennt den bestätigten Stand mit denselben Wörtern wie state_label und fügt den gemeldeten Betrag nur dort hinzu, wo eines der eigenen Zitate des Ereignisses ihn nennt und das label höchstens 64 Zeichen lang bleibt, sein state ist der bestätigte Stand, und seine finding_id nennt den Eintrag der Zeitleiste, auf dem es beruht und dessen Quellen die Detailansicht der Transaktion liefert. has_unseen_update ist true, wenn dieses Ereignis die Transaktion erreicht hat, nachdem Sie sie zuletzt im Dashboard geöffnet haben, oder wenn Sie sie nie geöffnet haben, und sonst false. Das Lesen einer Transaktion über /v1 zählt nie als Öffnen, und für einen Schlüssel ist das Feld null, weil ein Schlüssel kein Öffnen aufzeichnet.

Recherche

GET /v1/monitoring/targets, die Rechercheziele, also die Organisationen und, wo Personendaten eingeschaltet sind, die natürlichen Personen, die die Recherche im festen Turnus prüft, jede mit dem Ergebnis ihres letzten Laufs und dem nächsten Fälligkeitszeitpunkt. last_error ist run_failed, wenn der letzte Lauf fehlschlug, oder screening_allowance_reached, wenn die tiefe Recherche einer Person nicht gestartet wurde, weil das Konto, das sie angelegt hat, die Screenings dieses Monats verbraucht hat. Ein solches Ziel, das noch nie gelaufen ist, wartet, bis der Monat endet oder das Kontingent erweitert wird, mit dem ersten Moment des nächsten Monats (UTC) als next_run_at.
GET /v1/monitoring/catalog, der geprüfte Recherchekatalog Ihres Teams.
GET /v1/monitoring/sources, die Quellen, die die Recherche liest.

Länder und Referenzdaten

GET /v1/countries, der Länderindex.
GET /v1/countries/{iso3}, die belegten Einzelheiten zu einem Land, also Indikatoren, Risikoaufschlüsselung und zugehörige Transaktionen. Jede Indikatorzeile führt die Namensnennung ihres Datensatzes mit.
GET /v1/reference/datasets, die Referenzdatensätze hinter den Länderdaten, mit Angaben zu Lizenz und Namensnennung. Ein Datensatz, dessen Bedingungen eine erneute Veröffentlichung nicht erlauben, wird über die gesamte Schnittstelle zurückgehalten, statt ohne Namensnennung ausgeliefert zu werden.

Geografie

GET /v1/geography/summary, das aktive Deal Book nach Region und Land verdichtet, mit Anzahl, Volumen und Risikowerten.
GET /v1/geography/events, der geografische Ereignisfeed aus Referenzlisten, neueste zuerst.

Läufe und Entwicklungen

GET /v1/runs, die Rechercheläufe Ihres Teams, neueste zuerst, bei gleichem Zeitpunkt nach run_id, jeder mit seinem Team. entity_kind ist die Verzeichnisart des Gegenstands eines Laufs, wenn das Verzeichnis dessen genauen Namen führt, sonst null.
GET /v1/runs/{run_id}, ein Lauf mit seinen belegten Feststellungen, Quellen und Pressezitaten.
GET /v1/developments, der Feed der belegten Entwicklungen aus den Rechercheläufen Ihres Teams. sort ist recent oder score. Ein Recherchelauf zu einer natürlichen Person wird auf diesen drei Routen nur in Arbeitsbereichen ausgeliefert, in denen Personendaten eingeschaltet sind. Seine Zeilen im Feed tragen relevance_score null und werden nie nach einem Score geordnet.

Quellenangaben

POST /v1/citations/resolve, einer der drei POSTs dieser Schnittstelle, mit reiner Lesesemantik, es wird also nichts angelegt, nichts geändert und nichts eingereiht. Der Body führt Kennungslisten (record_ids, event_ids, assessment_ids; je bis zu 100 Kennungen), und jede angefragte Kennung erhält entweder ihre aufgelöste Nachweiszeile oder ein ausdrückliches null. Unbekannte Kennungen und Kennungen, die diese Schnittstelle nicht ausliefern darf, sind nicht voneinander zu unterscheiden, und ein Eintrag über eine natürliche Person wird nur in einem Arbeitsbereich aufgelöst, in dem Personendaten eingeschaltet sind. Ein aufgelöstes Ereignis führt headline, den Satz, den der Ereignisfeed dafür zeigt. Ein aufgelöster Datensatz führt published_fields, das beim Eintrag einer amtlichen Sanktionsliste zu einer Organisation, einem Schiff oder einem Luftfahrzeug die Felder enthält, die die Liste zu diesem Eintrag veröffentlicht, jeweils mit path und value, und bei jedem anderen Datensatz leer ist, sowie published_note, wie bei official_lists, wenn die Feldfamilien zurückgehalten wurden, die eine natürliche Person nennen können.

Eine Quellenangabe, deren source_url nur ein Suchformular und nicht den Eintrag selbst öffnet, führt locator, die Suchkoordinaten als Text. Das deutsche Insolvenzportal veröffentlicht keinen Link je Bekanntmachung, daher nennen seine Quellenangaben Gericht, Aktenzeichen und Veröffentlichungstag, und ihr Link öffnet die Startseite des Portals, den einzigen Link, den sein Betreiber erlaubt. Wo der Link den Eintrag öffnet, ist locator null.

Eine Quellenangabe kann notice führen, einen Text, der mit dem Eintrag anzuzeigen ist, wo immer der Eintrag angezeigt oder weitergegeben wird. Einträge aus dem Schweizerischen Handelsamtsblatt (SHAB) führen Swiss Official Gazette of Commerce (SOGC). Published by SECO. This is not an official publication., denn seine Nutzungsbedingungen verlangen die Nennung der Quelle und schließen den Eindruck aus, eine Wiedergabe sei eine amtliche Veröffentlichung. Für jede andere Quelle ist notice derzeit null.

Prüfprotokoll

GET /v1/audit-log.csv?from=JJJJ-MM-TT&to=JJJJ-MM-TT, das Prüfprotokoll Ihres eigenen Arbeitsbereichs als CSV, beide Tage eingeschlossen und höchstens 366 Tage, in der Reihenfolge des Protokolls mit den Spalten ts, action, actor, target_type, target_id, run_id, model und meta. In der Zeile eines Recherchelaufs (research_run oder budget_stop), eines Screenings (screening_completed oder budget_stop), einer Zusammenfassung eines Screenings (screening_resummarized), eines Briefinglaufs zu Deals (deal_briefing_run), eines Berichts (report_generated) oder eines Pakets (pack_generated), die ein Sprachmodell aufgerufen hat, nennt model das Modell, das seine Aufrufe beantwortet hat, mehrere mit + verbunden, und meta enthält served_models und served_providers mit der Zahl der Aufrufe, die jedes beantwortet hat, und, wo der Lauf ein anderes Modell geplant hatte, planned_models. Eine Zeile, die nicht zeigen kann, welches Modell geantwortet hat, lautet unknown und nennt nie das geplante Modell. Es enthält Anmeldungen, Bereitstellung und Rollenwechsel über SSO, entfernte Mitglieder und jede andere erfasste Aktion des Arbeitsbereichs, und nichts aus einem anderen Arbeitsbereich. Ein Schlüssel liest es nur, wenn ein Administrator ihn mit dem Prüfumfang erstellt hat (siehe Schlüssel und Zugangsverwaltung), und ein angemeldeter Nutzer liest es nur als Administrator. Jeder andere Aufrufer erhält 403 mit dem Code forbidden. Jeder Export wird selbst im Prüfprotokoll erfasst.

Dokumente

Die Dokumente als PDF, die das Dashboard herunterlädt, zum Ablegen in Ihrer eigenen Dokumentbibliothek, zum Beispiel einer Bibliothek in SharePoint über Power Automate (siehe SharePoint).

GET /v1/deals/{deal_id}/report.pdf, der Dealbericht.
GET /v1/deals/{deal_id}/pack.pdf?locale=de, das Ausschusspaket des Deals, mit den gespeicherten Ausschussvorgaben Ihres Arbeitsbereichs. locale ist en oder de; ohne Angabe gilt die Paketsprache Ihres Arbeitsbereichs.
GET /v1/entities/{entity_id}/report.pdf, der Gegenparteibericht, über die ID im Register, die GET /v1/entities liefert.
GET /v1/entities/{entity_id}/pack.pdf?locale=de, das Gegenparteipaket, über dieselbe ID im Register.
GET /v1/nodes/{node_id}/profile.pdf?locale=de, das Unternehmensprofil, jede Angabe mit ihrer Quelle, über die ID des Knotens des Graphen. Ein Unternehmen, dessen Registerform eine natürliche Person nennt, antwortet mit 404.

Ein Schlüssel lädt sie nur herunter, wenn ein Administrator ihn mit dem Berichtsumfang erstellt hat (siehe Schlüssel und Zugangsverwaltung), und ein angemeldeter Nutzer jeder Rolle lädt sie wie im Dashboard herunter. Jeder andere Aufrufer erhält 403 mit dem Code forbidden. Ein Schlüssel liest nur die Deals seines eigenen Teams, ein Deal eines anderen Teams antwortet also mit 404 wie eine unbekannte ID. Kein Download entwirft eine Zusammenfassung. Eine früher entworfene und geprüfte Zusammenfassung wird verwendet, sonst sagt das Dokument, dass es keine enthält. Solange jeder Platz zum Rendern belegt ist, antwortet ein Download mit 503, dem Code server_busy und Retry-After; siehe Fehler und Anfragebegrenzungen. Jeder Download wird im Prüfprotokoll als report_generated oder pack_generated erfasst.

Paginierung

Listenendpunkte nehmen limit und offset entgegen und antworten mit einer Antwortstruktur.

json

{ "items": [], "limit": 50, "offset": 0, "total": 0 }

total ist die genaue Anzahl nach Filterung. Das Maximum für limit ist 100, außer bei /v1/search, das bei 25 Treffern deckelt und mit einem eigenen Umschlag antwortet (siehe Suche). offset ist eine ganze Zahl von 0 bis 9223372036854775807; ein größerer Wert wird mit 422 abgelehnt. Die Route für Einträge eines Unternehmensknotens trägt neben diesen Schlüsseln records_total und registers.

Fehler

Jede 4xx eines Endpunkts unter /v1 trägt den strukturierten Umschlag, der unter Fehler und Anfragebegrenzungen beschrieben ist, mit Ausnahme einer 422 aus der Validierung, deren Body stattdessen den beanstandeten Parameter oder das beanstandete Feld benennt. Eine 404 ist einheitlich und bestätigt nie, ob eine Ressource außerhalb Ihres Arbeitsbereichs existiert.

Grundsätze

Lesend. Jeder Endpunkt ist ein GET, außer POST /v1/citations/resolve, POST /v1/portfolio/import und POST /v1/tenders/portals/upload, deren Semantik ein reiner Lesezugriff ist.
Personendaten folgen einer Regel, derselben wie im Dashboard. In einem Arbeitsbereich, in dem Personendaten eingeschaltet sind, werden die natürlichen Personen, die amtliche Register und die amtlichen Sanktionslisten nennen, mit ihren Belegen ausgeliefert, als Knoten, Kanten, Organe, Eigentümer, Listenfelder und als Prüfkandidaten des Abgleichs mit Sanktionslisten. Anderswo, und in der Sandbox immer, wird keine ausgeliefert, und eine Abfrage zu einer Person beantwortet dieselbe kanonische 404 wie eine unbekannte Kennung. Eine Person, die der Verarbeitung ihrer Daten widersprochen hat, wird nicht ausgeliefert. Keine Person wird je bewertet, eingestuft oder gereiht. Screenings natürlicher Personen auf negative Berichterstattung und Rechercheläufe zu einer natürlichen Person folgen derselben Regel. Sie werden als Feststellungen mit ihren Quellen ausgeliefert, ohne Einstufung, ohne Bewertung, ohne entworfene Zusammenfassung und ohne Relevanzwert. Ein Screening von Personen führt einen Namen und keinen Registereintrag, deshalb wird ein Widerspruch durch das Löschen des Screenings beantwortet. Screenings werden im Dashboard beauftragt, die API und MCP lesen sie. Jede Antwort, die eine natürliche Person ausliefert, schreibt einen Zugriffseintrag mit der Route, dem Schlüssel für die API und den ausgelieferten Kennungen, nie mit einem Namen.
Belegt. Antworten mit Feststellungen führen die Quellenangaben mit. Pressezitate sind auf 240 Zeichen gedeckelt, eine Passage je Quelle, stets mit URL der Quelle und Namensnennung; ein Zitat, das sich nicht zuordnen lässt, wird nicht ausgeliefert.
Nach Herausgeber eingestuft. Jede zitierte Quelle führt source_tier und tier_label mit. Stufe 1 ist eine Primärquelle, also die Partei der Transaktion oder die Stelle, die sie amtlich festhält; Stufe 2 ist Fachpresse; Stufe 3 ist ein Aggregator, wo auch jeder von uns nicht eingestufte Herausgeber landet. Bei einer Transaktion zählt eine abgerufene Seite auf der eigenen Website einer Partei, die diese Transaktion nennt, ebenfalls als Stufe 1, sobald die Transaktion auch eine abgerufene Seite eines anderen Herausgebers zitiert, den wir als Primärquelle oder Fachpresse einstufen. Eine Quelle, deren Text aus einem Suchindex statt von der Seite stammt, trägt text_provenance gleich snippet und zählt als ein Bericht, dessen Seite nicht geprüft ist.

Versionierung und Abkündigung

Die Version ist das Pfadpräfix, und /v1 ist die aktuelle Version.

Innerhalb von v1 kommen mit der Zeit Endpunkte, Antwortfelder, Werte und Fehlercodes hinzu. Schreiben Sie Clients deshalb so, dass sie unbekannte Felder und Werte ignorieren.
Eine Änderung innerhalb von v1, die ein Feld oder einen Wert entfernt oder umbenennt oder die Wirkung eines Parameters ändert, steht mit ihrem Datum in den Änderungen.
Die abgelöste Parallelroute unter Risiko je Unternehmen trägt im Dokument nach OpenAPI deprecated: true und antwortet weiterhin.
GET /v1/deals/merge/suggestions unter Transaktionen trägt im OpenAPI Dokument deprecated: true und antwortet seit dem 17. Oktober 2026 mit einer leeren Seite, weil Stonewake doppelte Transaktionen selbst bereinigt.