Drucken ist normalerweise die letzte Funktion, die einer Anwendung hinzugefügt wird, und die erste, die ausfällt. Wenn Du das Drucken über ezeep anbindest, erhält Deine Anwendung Cloud-Rendering, Druckererkennung und Auftragsweiterleitung, ohne dass Du einen Treiber-Stack warten musst.

Diese Seite richtet sich an Entwickler. Wenn Du ezeep über einen Assistenten verwenden möchtest, anstatt direkt damit zu entwickeln, beginne mit ezeep MCP in drei Schritten mit Deinem KI-Client verbinden.

Was ist der Unterschied zwischen Entwicklungszeit und Laufzeit?

Während der Entwicklungszeit liest ein KI-Tool die ezeep-Dokumentation, generiert Integrationscode und führt während Deiner Arbeit einen Testdruck durch. Deine bereitgestellte Anwendung ruft anschließend direkt die ezeep REST API auf, wobei MCP nicht beteiligt ist. Dies ist der normale Weg und derjenige, von dem die Anleitung des Servers ausgeht.

Agent-Frameworks bilden die Ausnahme. Dort bleibt MCP als dauerhafte Schnittstelle des Agents zum Drucken bestehen.

Welches Authentifizierungsmodell benötigst Du?

Leg dies fest, bevor Du etwas schreibst, denn die beiden Modelle sind nicht austauschbar. Ein späterer Wechsel bedeutet, dass Du die Authentifizierungsschicht neu erstellen musst.

Gemeinsam genutztes Konto. Eine ezeep-Identität druckt für die gesamte Anwendung. Kiosksysteme, interne Tools, serverseitige Automatisierung und API-Integrationen fallen in diese Kategorie. Die Einrichtung erfolgt über den im MCP-Server integrierten Kopplungsprozess: Fordere einen Kopplungscode an, melde Dich unter der zurückgegebenen URL an und tausche anschließend den Code gegen Tokens aus.

OAuth pro Benutzer. Jeder Endbenutzer meldet sich mit seinem eigenen ezeep-Konto an. Dies ist für Produkte mit mehreren Benutzern erforderlich. Standard OAuth 2.0 Authorization Code mit PKCE. Verwende einen vorhandenen öffentlichen PKCE-Client wieder, sofern Du einen hast, oder lass einen Organisationsadministrator einmalig einen Client registrieren.

Ersetze den Kopplungsprozess nicht durch OAuth pro Benutzer. Jeder Endbenutzer müsste zu ezeep weitergeleitet werden, sich anmelden, ein Token generieren und es anschließend in Deine Anwendung einfügen. Das ist keine geeignete Benutzererfahrung für eine produktionsbereite Anwendung.

Regeln, die Deine Integration zum Scheitern bringen, wenn Du sie ignorierst

Refresh Tokens können nur einmal verwendet werden. Jeder Austausch gibt ein neues Refresh Token zurück und macht das verwendete Token ungültig.

Speichere Refresh Tokens in einer beschreibbaren Datenbankzeile, niemals in Umgebungsvariablen oder einem Plattform-Secret-Store. Dies ist die häufigste Ursache für Fehler bei diesen Integrationen. Secret-Stores können von der laufenden Anwendung nicht beschrieben werden. Dadurch führt die erste Rotation zu einem dauerhaften Ausfall. Lies das Token aus der Datenbankzeile, tausche es aus und schreibe das neue Token wieder in dieselbe Zeile.

Die Client-ID gehört in einen Authorization-Header, nicht in den Request-Body. Erstelle eine Basic-Credential aus der Client-ID gefolgt von einem Doppelpunkt, ohne Secret.

Fordere einen Benutzer niemals zur Eingabe einer Client-ID, eines Client Secrets oder eines Refresh Tokens auf. Der MCP-Server stellt eine Standard-Client-ID bereit. Frag diese ab, anstatt einen Wert fest zu codieren.

Verwende den eigenen OAuth-Endpunkt des MCP-Servers nicht innerhalb Deiner Anwendung. Er ist ausschließlich für MCP-Host-Clients vorgesehen.

Registriere einen OAuth-Client pro Anwendung, nicht einen pro Build. Eine neue Client-ID ändert die Identität Deiner Anwendung und macht die Refresh Tokens aller bestehenden Benutzer ungültig, da jedes Refresh Token an den Client gebunden ist, der es ausgestellt hat. Neue Clients zählen außerdem gegen das Limit Deiner Organisation.

Wähle den Tenant-Modus sorgfältig. Ein Single-Tenant-Client lässt nur Benutzer der Eigentümerorganisation zu, während ein Multi-Tenant-Client Benutzer aus jeder ezeep-Organisation zulässt. Diese Auswahl ist festgelegt, sobald der Client erstellt wurde. Für die meisten Anwendungen ist Single-Tenant die gewünschte Option.

Wo befinden sich die API-Endpunkte?

ezeep läuft über drei Hosts, und jeder Host hat ein obligatorisches Pfadpräfix. Es gibt keine einzelne Basis-URL. Das Anhängen von Operationsnamen an einen einzigen Host wird daher fehlschlagen.

Endbenutzer-Druckoperationen befinden sich unter printapi.ezeep.com unter /sfapi/. Hier befinden sich die für einen Benutzer sichtbaren Drucker, Druckereigenschaften, die Vorbereitung eines Uploads, das Senden eines Auftrags, der Auftragsstatus und die unterstützten Dateitypen.

Drucker-, Gruppen- und Connector-Verwaltung befindet sich unter api2.ezeep.com unter /printing/v1/, mit Seitennummerierung.

Konto-, Benutzer- und OAuth-Operationen befinden sich unter account.ezeep.com unter /v1/, /oauth/ oder /auth/. Die Benutzerverwaltung befindet sich hier und umfasst die Benutzerliste, Benutzerdetails, das Profil des angemeldeten Benutzers und Einladungen.

Drei Details sind für die meisten frühen Fehler verantwortlich. Jeder Pfad benötigt seinen abschließenden Schrägstrich. Der Aufruf zur Vorbereitung des Uploads ist ausschließlich GET, wobei der Dateiname als Query-Parameter übergeben wird. Ein POST oder ein JSON-Body führt daher zu einem „method not allowed"-Fehler. Jede Druckanforderung enthält den Datei-Alias und den Typ auto.

Zu vermeidende Vorgehensweisen

Verzichte bei einer auf diese Weise aufgebauten Integration auf die ezeep JavaScript-Bibliothek, die Webkomponente für das Drucken und das CDN-Bundle, da der unterstützte Weg ein direkter REST-Aufruf aus einer serverseitigen Funktion ist. Fordere Benutzer nicht auf, ein Refresh Token von der Token-Generator-Seite in Deine Konfiguration zu kopieren, da diese Seite für Entwicklertests vorgesehen ist. Halte Zugangsdaten aus dem Frontend-Code heraus.

Wo befinden sich die aktuellen Anweisungen?

Im Server selbst. Er enthält einen eigenen Integrationsleitfaden, eine API-Referenz und Codebeispiele als aufrufbare Tools. Diese Ausgabe ist die aktuelle Quelle der Wahrheit. Lass einen KI-Client bei der Entwicklung diese Ressourcen lesen, anstatt mit allgemeinem Wissen über ezeep zu arbeiten, das schneller veraltet als die Plattform.

FAQs

Benötige ich MCP in meiner bereitgestellten Anwendung? Nur bei Agent-Frameworks. Eine herkömmliche Anwendung verwendet MCP während der Entwicklungszeit, um die Integration zu generieren, und ruft zur Laufzeit direkt die ezeep REST API auf.

Warum funktioniert meine Integration nach einem Tag nicht mehr? Fast immer liegt es am Refresh Token. Tokens werden bei jedem Austausch rotiert. Wenn sie in Umgebungsvariablen oder einem Plattform-Secret-Store gespeichert werden, wird das neue Token nie zurückgeschrieben. Verschiebe sie in eine Datenbankzeile, die Deine Anwendung überschreiben kann.

Kann ich einen OAuth-Client für mehrere Anwendungen wiederverwenden? Verwende ihn für verschiedene Builds derselben Anwendung wieder. Eine separate Anwendung benötigt einen eigenen Client, da Refresh Tokens an den Client gebunden sind, der sie ausgestellt hat, und die Rotation der Client-Identität bestehende Benutzer ungültig macht.

Welchen Scope sollte ich anfordern? Printing deckt Druckoperationen ab und accounts administrative Vorgänge. Fordere nur die Berechtigungen an, die die Anwendung tatsächlich verwendet.

Gibt es ein Rate Limit? Aufrufe laufen über dieselbe Plattform wie die REST API und werden auf dasselbe Kontingent angerechnet, unabhängig davon, ob sie über MCP oder direkt erfolgen.