Connect your application to kiosk hardware.

Start with an agreed runtime and device configuration

Request the approved runtime package, installation instructions, release identity and device driver configuration for your evaluation. The 0.5.20 runtime source line covered by this reference uses Java 21. The application can use any language with an HTTP client.

Confirm the exact operating system, architecture, device model, firmware, connection and required operations. Install only the supplied runtime and approved drivers on the evaluation machine. Verify permissions under the account that will run the kiosk. Confirm SDK driver support for each peripheral and operating system separately from Satellite fleet-management support.

The integration team supplies the service address and authentication requirements for the deployment. Keep hardware APIs on the approved local or private network boundary. Configure authentication, transport security, browser origins and access permissions before connecting a client.

Reference edition 2026-10-26 · read-only status

Check a configured document reader without starting a scan

This reference covers the hardware-client 0.5.20 status contract. Match it to your supplied runtime build before use. The document-reader module must be enabled; otherwise this route may be unavailable.

GET /api/hardware/document-reader/get-status returns the configured reader’s reported status inside the shared response envelope. Use this read-only request in your authorised evaluation environment. The response fragments below use synthetic values.

curl --config "$AZIMUT_CURL_CONFIG" \
  --max-time 10 --fail-with-body \
  "$AZIMUT_BASE_URL/api/hardware/document-reader/get-status"

{
  "code": "0000",
  "message": "OK",
  "data": { "status": "WORKING" }
}

{
  "code": "0000",
  "message": "OK",
  "data": { "status": "IN_ERROR" }
}

The envelope code 0000 says the API call succeeded; it does not by itself say the device is usable. Inspect data.status. The status model includes WORKING, NOT_FOUND and error or device-condition values. Which states a particular driver returns must be confirmed with that driver. Test the complete customer transaction after checking readiness.

The shared envelope also has errors, eventId and timestamp fields in this source line; fragments above omit them. Preserve the supplied event reference for support. Treat a non-success HTTP result, non-success envelope code, missing data or unrecognised status as a separate outcome to handle. An authentication rejection or an unavailable module may not use the same JSON body.

Timeouts, retries and transaction outcomes

A bounded status read can be repeated according to your polling policy. A timed-out device action is different: cash may already be retained, a card may already be dispensed or a downstream posting may already be accepted. Do not apply status-read retries to those operations. Agree each operation’s correlation, duplicate-request and reconciliation contract before implementing retries.

Ask for the release-specific reference and change notes with the evaluation package. Confirm supported and retired versions, upgrade ownership, rollback constraints and the support window in writing.

Continue with the application guides

These guides explain integration patterns. Check their example contract against your supplied runtime before running any device action, and use a controlled test setup.