Anderer Software erlauben, Ihre Daten zu lesen

Das API Studio: Veröffentlichung eines Bildschirms nach dem anderen, Ausstellung eines Schlüssels, Anheften an eine Adresse und die gleiche Veröffentlichung wie ein MCP-Server für einen KI-Agenten.

Früher oder später benötigt ein externes TRANXACT Ihre Daten: ein Reporting-Tool, das System eines Partners, eine Website mit Preisliste oder ein KI-System mit Fragen zu Ihrem Unternehmen. Im API Studio unter „Plattform“ legen Sie fest, welche Daten zugänglich gemacht werden dürfen – Bildschirm für Bildschirm, Spalte für Spalte.

Nichts ist von außen erreichbar, bis es jemand veröffentlicht. Es gibt keine Einstellung, die alles freischaltet, und keinen Schlüssel, der alles zugänglich macht. Eine brandneue Bereitstellung hat überhaupt keine API-Schnittstelle, und das ist der richtige Ausgangspunkt, anstatt etwas, das erst aktiviert werden muss.

Die vier Entscheidungen, der Reihe nach

Was	Was es entscheidet	Wer macht das normalerweise?
Eine Enthüllung	Es ist ungewiss, ob dieser eine Bildschirm das Unternehmen überhaupt verlässt – welche Spalten, welche Zeilen und ob irgendetwas davon zurückgeschrieben werden kann.	Wem gehören die Daten?
Ein Kunde	Es gibt diese eine Software, wie sie heißt, wen man diesbezüglich anrufen kann und für welchen Ihrer Benutzer sie zuständig ist.	Wer auch immer die Integration leitet
Ein Zuschuss	Damit dieser Kunde mit diesen Verben diese Reichweite erzielen kann.	Wer auch immer die Integration leitet
Eine zulässige Adresse	Woher der Schlüssel präsentiert werden kann – vom Browserursprung, von einem Host, von einer Serveradresse oder von einem Netzwerk.	Wer auch immer die Integration leitet

Die Plattform stellt hierfür drei Rollen bereit und trennt diese bewusst. Ein API-Publisher entscheidet, welche Daten freigegeben werden dürfen, und kann keine Schlüssel ausstellen. Ein API-Registrar stellt Schlüssel aus und kann keine Sicherheitslücken schaffen. Ein API-Reviewer liest alle Daten, ändert aber nichts. Wenn eine einzelne Person die Gehaltsabrechnungstabelle veröffentlicht und sich selbst einen Schlüssel ausstellt, der diese Tabelle lesen kann, entsteht ein vollständiger, nicht überwachter Exportprozess, bei dem jeder Schritt wie eine gewöhnliche administrative Änderung aussieht.

Veröffentlichung eines Bildschirms

Öffnen Sie die Plattform → API Studio und wählen Sie einen Bildschirm aus. Die Liste enthält alle Bildschirme der Konsole, direkt aus dem Produkt ausgelesen – also auch alle Bildschirme, die in dieser Version enthalten sind.
Markieren Sie die Spalten, die möglicherweise übertragen werden. Nicht markierte Einträge werden jemals gesendet: weder in einer Liste noch in einem einzelnen Datensatz, noch in der Antwort eines Schreibvorgangs. Es werden bewusst keine Einträge markiert.
Entscheiden Sie sich für die Verben. Lesen ist standardmäßig aktiviert; Erstellen, Ändern und Löschen erfordern jeweils eine separate Entscheidung, da das Zulassen, dass das System Ihren Artikelstamm liest, und das Zulassen, dass das System ihn löscht, nicht derselbe Satz sind.
Optional können die Zeilen eingeschränkt werden – nur gebuchte Rechnungen, nur dieses Jahr. Es handelt sich um denselben Filter, der in jeder Listenansicht angezeigt wird, serverseitig bei jedem Anruf angewendet wird und durch keine Eingabe des Anrufers erweitert werden kann.
Heb es auf. Es ist nur ein Entwurf, und ein Entwurf führt zu nichts. Veröffentliche es erst, wenn du es wirklich ernst meinst.
Klicken Sie auf „Vorschau“, bevor Sie jemandem einen Schlüssel geben. Dort wird genau angezeigt, was ein Partner erhalten würde und wie viele Spalten zurückgehalten wurden.

Registrierung der Software

Ein Client ist ein Datensatz einer Software: Name, Funktion, Ansprechpartner und – ganz wichtig – welcher Benutzer sie verwendet. Jeder Aufruf, den der Schlüssel tätigt, erfolgt im Namen dieser Person. Was diese Person nicht tut, tut der Schlüssel möglicherweise auch nicht.

Das ist das mit Abstand wichtigste Feld auf dem Bildschirm, und deshalb kann eine Zugriffsbeschränkung den Zugriff nur einschränken, aber niemals erweitern. Richten Sie eine Taste auf einen Benutzer, der genau für diesen Zweck vorgesehen ist und die kleinstmögliche Berechtigung besitzt – nicht auf einen Administrator, nur weil es gerade praktischer ist.

Der Schlüssel selbst wird nur einmal bei der Ausstellung angezeigt und danach nie wieder. Die Ausstellung eines neuen Schlüssels deaktiviert den alten sofort. Ein Schlüssel kann entzogen werden, ohne den Kunden zu löschen; das Register vermerkt daher weiterhin, wer wann Zugriff darauf hatte.

Wo ein Schlüssel verwendet werden kann

Ein Schlüssel ohne zulässige Adressen hat keine Reichweite. Werden keine Adressen angegeben, gilt dies als nicht erreichbar und ist niemals von irgendwo erreichbar, da das gesamte Risiko in einem durchgesickerten Schlüssel besteht, der auf jedem Laptop weltweit funktioniert. Es gibt vier Arten von Zugriffen: Browserursprung, verweisender Host, einzelne Adresse oder Netzwerk im CIDR-Format.

Ein Client kann als von überall aus nutzbar markiert werden, und manchmal ist das auch korrekt – beispielsweise bei einem Partner, dessen Ausgangsadresse sich tatsächlich ändert. Es handelt sich dabei um eine bewusste Umstellung mit einem entsprechenden Warnhinweis und nicht um die Standardeinstellung.

Was man demjenigen schicken sollte, der die Integration durchführt

Das Studio gibt die vier Adressen aus. Die Basisadresse ist /api/v1, der Schlüssel wird in einem Authorization: Bearer-Header gespeichert, /api/v1/resources listet auf, worauf dieser Schlüssel zugreifen kann, und /api/v1/openapi.json entspricht einem OpenAPI 3.1-Dokument.

Beide werden aus dem Schlüssel generiert, der sie anfordert. Einem Partner wird niemals ein Dokument mit vierzig Endpunkten ausgehändigt, die er nicht aufrufen kann: Sein Dokument beschreibt exakt, welche Endpunkte er aufrufen kann und nichts anderes. Es kann auch keinen Pfad beschreiben, der abgelehnt würde, da es aus denselben Zeilen erstellt wird, die der Anfragebehandler prüft.

Die gleichen Daten für einen KI-Agenten

Die Adresse /api/v1/mcp ist ein Server für das Model Context Protocol. Einem Agenten, der sich damit verbindet, wird für jede mögliche Funktion des Schlüssels ein Werkzeug bereitgestellt – und nichts anderes: kein Werkzeug für nicht veröffentlichte Daten, kein Werkzeug für nicht implementierte Funktionen. Es handelt sich um dieselbe Veröffentlichung, nur für ein Modell und nicht für einen Entwickler beschrieben, sodass die beiden stets synchronisiert sind.

Schreiben Sie die MCP-Anweisungen auf den Client. Nur dort wird dem Modell mitgeteilt, dass diese Tools auf ein Live-Buch und nicht auf eine Testumgebung zugreifen, und nur dort können Sie festlegen, dass mit „Aufträgen“ hier Bestellungen und nicht Verkaufsaufträge gemeint sind.

Was passiert bei jedem Anruf?

Ein veröffentlichter Aufruf ist kein direkter Zugriff auf die Datenbank. Er wird authentifiziert, anhand der Zugriffsrechte und Berechtigungen geprüft und anschließend über die plattformeigene API als Ihr Benutzer ausgeführt – derselbe Weg, den auch die Konsole nutzt. Unternehmens- und Geschäftsbereichsbeschränkungen, Standortbeschränkungen, Sperrfristen, Buchungsregeln, benutzerdefinierte Felder, benutzerdefinierte Logik, Bearbeitbarkeit und der Prüfpfad gelten alle, da derselbe Code ausgeführt wird.

Jeder Anruf wird protokolliert, ob er genehmigt oder abgelehnt wurde, inklusive Begründung. Das Protokoll befindet sich unter Plattform → API Studio → API-Anrufprotokoll. Die interessanteste Zeile darin ist ein Schlüssel, der von einer nicht autorisierten Adresse übermittelt wurde.

Wenn es nicht funktioniert

Was der Partner sieht	Was es bedeutet
Dieser API-Schlüssel wird nicht erkannt.	Falscher Schlüssel, oder es wurde inzwischen ein neuer ausgestellt.
Dieser API-Schlüssel hat keine zulässigen Adressen	Bisher hat noch niemand gesagt, wo es eingesetzt werden könnte.
Dieser API-Schlüssel darf von hier aus nicht verwendet werden.	Es nennt den Ursprung und die Adresse, an der die Nachricht tatsächlich ankam – in der Regel hat der Partner die Server gewechselt.
Hier wird nichts als X veröffentlicht.	Der Name ist falsch, oder dieser Schlüssel hat keine Berechtigung, darauf zuzugreifen, oder es handelt sich noch um einen Entwurf.
Dieser Schlüssel erzeugt möglicherweise kein X.	Die Offenlegung oder die Förderung erlaubt dieses Verb nicht.
Sie haben keine Berechtigung, X anzuzeigen.	Die Förderung ist in Ordnung, der Benutzername jedoch nicht. Das Studio listet diese Informationen auf, bevor ein Partner sie finden muss.

Die Clientliste zeigt eine Spalte für die Bereitschaft anstelle des reinen Status an, da ein Client zwar aktiv sein und einen Schlüssel besitzen kann, aber dennoch nichts erreichen kann – kein Benutzer, unter dem er ausgeführt werden kann, keine zulässige Adresse, keine Genehmigung. So vergeht ein Nachmittag: Die Clientliste zeigt „aktiv“ an, während jeder Anruf abgelehnt wird.