L’impression est généralement la dernière fonctionnalité ajoutée à une application et la première à tomber en panne. La gérer via ezeep permet à votre application de bénéficier du rendu cloud, de la découverte des imprimantes et du routage des travaux, sans avoir à maintenir une infrastructure de pilotes.

Cette page s’adresse aux développeurs. Pour utiliser ezeep via un assistant plutôt que de développer directement avec ezeep, commencez par Connecter ezeep MCP à votre client d’IA en trois étapes.

Quelle est la différence entre la phase de développement et l’exécution ?

Pendant la phase de développement, un outil d’IA lit la documentation ezeep, génère le code d’intégration et effectue un test d’impression pendant que vous travaillez. Votre application déployée appelle ensuite directement l’API REST ezeep, sans que MCP intervienne. C’est le parcours normal et celui supposé par les instructions du serveur.

Les frameworks d’agents constituent l’exception. Dans ce cas, MCP reste en place comme interface permanente de l’agent pour l’impression.

Quel modèle d’authentification devez-vous utiliser ?

Choisissez-le avant d’écrire quoi que ce soit, car les deux modèles ne sont pas interchangeables et un changement ultérieur implique de refaire la couche d’authentification.

Compte partagé. Une seule identité ezeep imprime pour l’ensemble de l’application. Les bornes, outils internes, automatisations côté serveur et intégrations API correspondent à ce modèle. La configuration passe par le processus d’association intégré au serveur MCP : demandez un code d’association, connectez-vous à l’URL qu’il renvoie, puis échangez le code contre des jetons.

OAuth par utilisateur. Chaque utilisateur final se connecte avec son propre compte ezeep, ce qui est nécessaire pour les produits multi-utilisateurs. OAuth 2.0 Authorization Code standard avec PKCE. Réutilisez un client PKCE public existant lorsque vous en avez un, ou demandez à un administrateur de l’organisation d’en enregistrer un une seule fois.

Ne remplacez pas OAuth par utilisateur par le processus d’association. Chaque utilisateur final devrait être redirigé vers ezeep, se connecter, générer un jeton et le recopier dans votre application, ce qui n’est pas une expérience adaptée à un produit prêt à être déployé.

Règles qui peuvent faire échouer votre intégration si vous les ignorez

Les refresh tokens ne sont utilisables qu’une seule fois. Chaque échange renvoie un nouveau refresh token et invalide celui que vous avez utilisé.

Stockez les refresh tokens dans une ligne de base de données modifiable, jamais dans des variables d’environnement ou dans un gestionnaire de secrets de plateforme. C’est la cause la plus fréquente d’échec de ces intégrations. Les gestionnaires de secrets ne sont pas modifiables depuis l’application en cours d’exécution, donc la première rotation la rend définitivement inutilisable. Lisez le token depuis la ligne, échangez-le, puis écrivez le nouveau dans cette même ligne.

Le client ID doit être placé dans un en-tête Authorization, et non dans le corps de la requête. Créez un identifiant Basic à partir du client ID suivi de deux-points, sans secret.

Ne demandez jamais à un utilisateur de saisir un client ID, un client secret ou un refresh token. Le serveur MCP fournit un client ID par défaut. Demandez-le-lui plutôt que de coder une valeur en dur.

N’utilisez pas le propre endpoint OAuth du serveur MCP dans votre application. Il est destiné aux clients hôtes MCP et à rien d’autre.

Enregistrez un seul client OAuth par application, et non un par build. Un nouveau client fait tourner l’identité de votre application et invalide les refresh tokens de tous les utilisateurs existants, car chaque refresh token est lié au client qui l’a émis. Les nouveaux clients comptent également dans la limite de votre organisation.

Choisissez soigneusement le mode tenant. Un client single-tenant n’autorise que les utilisateurs de l’organisation propriétaire, tandis qu’un client multi-tenant autorise les utilisateurs de n’importe quelle organisation ezeep. Ce choix est définitif une fois le client créé, et single est ce que la plupart des applications souhaitent.

Où se trouvent les endpoints de l’API ?

ezeep fonctionne sur trois hôtes et chacun possède un préfixe de chemin obligatoire. Il n’existe pas d’URL de base unique, et ajouter les noms des opérations à un seul hôte entraînera un échec.

Les opérations d’impression des utilisateurs finaux se trouvent sur printapi.ezeep.com sous /sfapi/. La liste des imprimantes visibles par un utilisateur, les propriétés des imprimantes, la préparation d’un téléversement, l’envoi d’un travail, le statut d’un travail et les types de fichiers pris en charge se trouvent tous ici.

La gestion des imprimantes, des groupes et des connecteurs se trouve sur api2.ezeep.com sous /printing/v1/, avec pagination.

Les opérations liées au compte, aux utilisateurs et à OAuth se trouvent sur account.ezeep.com sous /v1/, /oauth/ ou /auth/. La gestion des utilisateurs se trouve ici et couvre la liste des utilisateurs, les détails d’un utilisateur, le profil de l’utilisateur connecté et les invitations.

Trois détails expliquent la plupart des premiers échecs. Chaque chemin doit se terminer par une barre oblique. L’appel de préparation du téléversement est uniquement GET avec le nom du fichier comme paramètre de requête. Un POST ou un corps JSON renvoie donc une erreur « method not allowed ». Chaque demande d’impression contient l’alias du fichier et un type défini sur auto.

Approches à éviter

Évitez la bibliothèque JavaScript ezeep, le composant Web d’impression et le bundle CDN pour une intégration construite de cette manière, car la méthode prise en charge consiste à utiliser directement REST depuis une fonction côté serveur. Ne demandez pas à un utilisateur de copier un refresh token depuis la page du générateur de tokens dans votre configuration, car cette page est destinée aux tests des développeurs. Gardez les identifiants hors du code front-end.

Où trouver les instructions actuelles ?

À l’intérieur du serveur. Il contient son propre guide d’intégration, sa référence d’API et ses exemples de code sous forme d’outils appelables, et cette sortie constitue la source de référence actuelle. Lors d’une intégration via un client d’IA, demandez-lui de lire ces ressources plutôt que de s’appuyer sur ses connaissances générales d’ezeep, qui vieillissent plus vite que la plateforme.

FAQ

Ai-je besoin de MCP dans mon application déployée ? Uniquement pour les frameworks d’agents. Une application classique utilise MCP pendant la phase de développement pour générer l’intégration, puis appelle directement l’API REST ezeep lors de l’exécution.

Pourquoi mon intégration a-t-elle cessé de fonctionner après une journée ? Presque toujours à cause du refresh token. Les tokens sont renouvelés à chaque échange, et leur stockage dans des variables d’environnement ou dans un gestionnaire de secrets de plateforme signifie que le nouveau token n’est jamais réécrit. Déplacez-les vers une ligne de base de données que votre application peut écraser.

Puis-je réutiliser un même client OAuth pour plusieurs applications ? Réutilisez-le pour les différents builds de la même application. Une application distincte doit disposer de son propre client, car les refresh tokens sont liés au client qui les a émis et la rotation de l’identité du client invalide les utilisateurs existants.

Quel scope dois-je demander ? Printing couvre les opérations d’impression et accounts couvre les opérations administratives. Demandez uniquement ce que l’application utilise réellement.

Existe-t-il une limite de débit ? Les appels passent par la même plateforme que l’API REST et comptent dans le même quota, qu’ils arrivent via MCP ou directement.