Print from a web application to a local printer
Printing from a web application should begin on your backend, not in the browser print dialog. This lets the product select the right printer, prevent accidental duplicates and show the actual job result.
Recommended architecture
The frontend sends your backend a business document reference and the configured location or printer choice. The backend generates or fetches the file, calls the CloudPrint Public API and returns its own operation identifier. Neither client_secret nor the Bearer token reaches the browser.
Printer selection
During setup, read printers from GET /api/v1/printers and persist the stable printer_id. The UI may show the printer name, agent and online state, but a display name is not a routing key.
Operator experience
After a user selects Print, show accepted, waiting, printing and final states. Prevent accidental double-clicks while allowing an intentional reprint as a new operation. A failure view should include a readable reason and a reference support can use.
Surviving network failures
The backend should send a stable Idempotency-Key, persist print_job_id and continue status tracking after a page refresh. After a timeout, do not assume the request failed; repeat the same idempotent request or recover the stored result first.
Patterns to avoid
Do not call the agent from browser code, expose printers to the internet, put credentials in localStorage or treat an accepted HTTP request as proof of printing. Only a terminal print job status describes the outcome.
Production checklist
- Create jobs from the backend instead of depending on the browser print dialog.
- Keep API credentials on the backend and scope them to the owning account.
- Store the stable printer identity instead of relying only on a display name.
- Handle terminal status, retry policy and duplicate-print protection explicitly.