Drucken ist normalerweise die letzte Funktion, die einer Anwendung hinzugefügt wird, und die erste, die ausfällt. Wenn Sie das Drucken über ezeep anbinden, erhält Ihre Anwendung Cloud-Rendering, Druckererkennung und Auftragsweiterleitung, ohne dass Sie einen Treiber-Stack warten müssen.
Diese Seite richtet sich an Entwickler. Wenn Sie ezeep über einen Assistenten verwenden möchten, anstatt direkt damit zu entwickeln, beginnen Sie mit ezeep MCP in drei Schritten mit Ihrem 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 Ihrer Arbeit einen Testdruck durch. Ihre 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ötigen Sie?
Legen Sie dies fest, bevor Sie etwas schreiben, denn die beiden Modelle sind nicht austauschbar. Ein späterer Wechsel bedeutet, dass Sie die Authentifizierungsschicht neu erstellen müssen.
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: Fordern Sie einen Kopplungscode an, melden Sie sich unter der zurückgegebenen URL an und tauschen Sie 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. Verwenden Sie einen vorhandenen öffentlichen PKCE-Client wieder, sofern Sie einen haben, oder lassen Sie einen Organisationsadministrator einmalig einen Client registrieren.
Ersetzen Sie 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 Ihre Anwendung einfügen. Das ist keine geeignete Benutzererfahrung für eine produktionsbereite Anwendung.
Regeln, die Ihre Integration zum Scheitern bringen, wenn Sie sie ignorieren
Refresh Tokens können nur einmal verwendet werden. Jeder Austausch gibt ein neues Refresh Token zurück und macht das verwendete Token ungültig.
Speichern Sie 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. Lesen Sie das Token aus der Datenbankzeile, tauschen Sie es aus und schreiben Sie das neue Token wieder in dieselbe Zeile.
Die Client-ID gehört in einen Authorization-Header, nicht in den Request-Body. Erstellen Sie eine Basic-Credential aus der Client-ID gefolgt von einem Doppelpunkt, ohne Secret.
Fordern Sie 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. Fragen Sie diese ab, anstatt einen Wert fest zu codieren.
Verwenden Sie den eigenen OAuth-Endpunkt des MCP-Servers nicht innerhalb Ihrer Anwendung. Er ist ausschließlich für MCP-Host-Clients vorgesehen.
Registrieren Sie einen OAuth-Client pro Anwendung, nicht einen pro Build. Eine neue Client-ID ändert die Identität Ihrer 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 Ihrer Organisation.
Wählen Sie 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
Verzichten Sie 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. Fordern Sie Benutzer nicht auf, ein Refresh Token von der Token-Generator-Seite in Ihre Konfiguration zu kopieren, da diese Seite für Entwicklertests vorgesehen ist. Halten Sie 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. Lassen Sie 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. Verschieben Sie sie in eine Datenbankzeile, die Ihre Anwendung überschreiben kann.
Kann ich einen OAuth-Client für mehrere Anwendungen wiederverwenden? Verwenden Sie 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. Fordern Sie 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.