Hardware integration API
Thermal receipt printing API for self-service kiosks
Azimut SDK lets kiosk applications print receipts through a stable API while the platform handles printer readiness, device faults, retries, and transaction logging.
Why receipt printing needs an SDK layer
In a kiosk, the receipt is part of the transaction record. The application needs to know whether the printer is ready, whether the job succeeded, and what to do when paper or device faults block the flow.
Check printer readiness
Confirm that the printer is online and ready before the kiosk begins a receipt-required flow.
Create the receipt payload
Generate the transaction receipt from a template, amount, reference number, timestamp, and service result.
Send the print job
Call a stable SDK method while the platform handles the attached printer and protocol details.
Confirm or recover
Record success, retry when appropriate, or surface a controlled failure when the printer cannot complete the job.
Device states
Track printer health before it affects a customer session
A useful printing API does more than send text. It exposes the state that determines whether the kiosk can safely start or complete a receipt-required transaction.
API contract for developers
Developers call SDK methods for printer status and print jobs. The business application stays focused on the workflow instead of device protocol handling.
Cloud-orchestrated, locally controlled
Backends can prepare receipt context, but the kiosk runtime should control the local printer and report device state.
Fault-aware transactions
Print failures, paper faults, and offline devices should be logged against the transaction and surfaced to operations.
Thermal receipt printing API FAQs
What is a thermal receipt printing API?
A thermal receipt printing API lets a kiosk application send receipt jobs through a stable software contract, eliminating device-specific logic for each printer model.
Can Azimut SDK support cloud printing API workflows for thermal printers?
Azimut SDK supports cloud-orchestrated kiosk workflows with local device control. The backend prepares the transaction and receipt context, while the kiosk runtime controls the local printer and reports device state.
Why not print directly from the browser?
Browser printing is weak for unattended kiosks because it does not reliably expose device state, paper faults, retry behavior, or transaction-level logging. Receipt-required workflows need runtime-level printer control.
Does the API handle printer health monitoring?
The SDK reports printer readiness, fault states, and transaction-level print results into the wider kiosk monitoring model.