Printing is usually the last thing added to an application and the first thing that breaks. Wiring it through ezeep gives your app cloud rendering, printer discovery and job routing without a driver stack to maintain.
This page is for developers. To use ezeep through an assistant rather than build against it, start with Connect ezeep MCP to your AI client in three steps.
What is the difference between build time and runtime?
At build time, an AI tool reads the ezeep documentation, generates integration code and runs a test print while you work. Your deployed application then calls the ezeep REST API directly, with MCP out of the loop. That is the normal path and the one the server's guidance assumes.
Agent frameworks are the exception. There, MCP stays in place as the agent's permanent interface to printing.
Which authentication model do you need?
Pick this before writing anything, because the two models are not interchangeable and switching later means redoing the auth layer.
Shared account. One ezeep identity prints for the whole application. Kiosks, internal tools, server-side automation and API integrations fit here. Setup runs through the pairing flow built into the MCP server: request a pairing code, sign in at the URL it returns, then exchange the code for tokens.
Per-user OAuth. Each end user signs in with their own ezeep account, which is what multi-user products need. Standard OAuth 2.0 Authorization Code with PKCE. Reuse an existing public PKCE client where you have one, or have an organization admin register a client once.
Do not substitute the pairing flow for per-user OAuth. Every end user would have to be redirected to ezeep, sign in, generate a token and paste it back into your application, which is not a shipping experience.
Rules that will break your integration if you ignore them
Refresh tokens are single use. Each exchange returns a new refresh token and invalidates the one you used.
Store refresh tokens in a writable database row, never in environment variables or a platform secret store. This is the most common way these integrations fail. Secret stores are not writable from the running application, so the first rotation breaks it permanently. Read the token from the row, exchange it, write the new one back to the same row.
The client ID belongs in an Authorization header, not the request body. Build a Basic credential from the client ID followed by a colon, with no secret.
Never prompt a user for a client ID, client secret or refresh token. The MCP server supplies a default client ID, so ask it rather than hardcoding a value.
Do not reuse the MCP server's own OAuth endpoint inside your application. It exists for MCP host clients and nothing else.
Register one OAuth client per application, not one per build. A new client ID rotates your app's identity and invalidates every existing user's refresh tokens, because each refresh token is bound to the client that issued it. New clients also count against your organization's limit.
Choose the tenant mode carefully. A single-tenant client admits only users of the owning organization, while a multi-tenant client admits users from any ezeep organization. The choice is fixed once the client exists, and single is what most applications want.
Where do the API endpoints live?
ezeep runs across three hosts and each one has a mandatory path prefix. There is no single base URL, and appending operation names to one host will fail.
End-user print operations live at printapi.ezeep.com under /sfapi/. Listing the printers a user can see, printer properties, preparing an upload, submitting a job, job status and supported file types all sit here.
Printer, group and connector management lives at api2.ezeep.com under /printing/v1/, paginated.
Account, user and OAuth operations live at account.ezeep.com under /v1/, /oauth/ or /auth/. User management sits here, covering the user list, user detail, the signed-in user's own profile, and invitations.
Three details account for most early failures. Every path needs its trailing slash. The upload preparation call is GET only with the filename as a query parameter, so a POST or a JSON body returns a method-not-allowed error. Every print request carries the file alias and a type of auto.
Patterns to avoid
Skip the ezeep JavaScript library, the printing web component and the CDN bundle for an integration built this way, because the supported path is direct REST from a server-side function. Do not ask a user to paste a refresh token from the token generator page into your configuration, since that page exists for developer testing. Keep credentials out of front-end code.
Where do the current instructions live?
Inside the server. It carries its own integration guide, API reference and code examples as callable tools, and that output is the current source of truth. Building through an AI client, have it read those rather than work from general knowledge about ezeep, which ages faster than the platform does.
FAQs
Do I need MCP in my deployed application? Only for agent frameworks. A conventional application uses MCP at build time to generate the integration, then calls the ezeep REST API directly at runtime.
Why did my integration stop working after a day? Almost always the refresh token. Tokens rotate on every exchange, and storing them in environment variables or a platform secret store means the new one never gets written back. Move them to a database row your application can overwrite.
Can I reuse one OAuth client across several applications? Reuse it across builds of the same application. A separate application wants its own client, since refresh tokens are bound to the client that issued them and rotating the client identity invalidates existing users.
Which scope should I request? Printing covers print operations and accounts covers administrative ones. Request what the application genuinely uses.
Is there a rate limit? Calls run through the same platform as the REST API and count against the same quota, whether they arrive through MCP or directly.