Control Kiosk Hardware from Python

Published: 18/09/2026

Python shows up around self-service hardware in more places than the kiosk UI. It powers integration harnesses, test rigs, back-office automation, and quick prototypes that prove a flow before a platform team commits to it. Each of those jobs needs to talk to the same devices the production application talks to.

That is where a JSON API earns its keep. The Python code below runs against the same dispenser endpoints a .NET or Java application would call, with no binding to install and no serial protocol to implement.

Check the device before a session needs it

A dispenser that is out of notes or reporting a fault should be discovered before a customer reaches the cash step. The readiness check is a single GET request.

1
2
3
4
5
6
7
8
9
10
11
import requests

BASE = "http://localhost:8080"

status = requests.get(
    f"{BASE}/api/hardware/cash-dispenser/check-dispenser",
    timeout=10,
).json()

if status["code"] != "0000":
    raise RuntimeError(f"Dispenser not ready: {status['message']}")

A code of 0000 means the device answered in a ready state. Any other code carries a message that a test harness can print and a support team can read.

Dispense an amount and read the result

The dispense call is a POST with a JSON body. The response uses the same envelope as every other device operation, so error handling is written once.

1
2
3
4
5
6
7
8
result = requests.post(
    f"{BASE}/api/hardware/cash-dispenser/dispense-amount",
    json={"amount": "5000"},
    timeout=30,
).json()

if result["code"] != "0000":
    raise RuntimeError(f"Dispense failed: {result['message']}")

The SDK owns the device protocol and the mechanical sequence behind the call. The Python process only decides when the dispense should happen and what to do when it does not.

Where Python fits in a kiosk project

In production, the kiosk application is usually written in whatever stack the platform team already operates, and the SDK serves it a local JSON API. Python tends to appear around that application rather than inside it: a harness that exercises every device on a new machine before it ships, a script that runs a cash cycle as part of acceptance testing, or an operations tool that checks dispenser state across a fleet over the network.

Because the API is plain HTTP with JSON payloads, those tools do not need the kiosk application to expose anything special. A test rig can drive the same endpoint the production flow drives, which keeps what is tested and what is shipped on the same contract.

Try it yourself

Book a demo

See how Azimut SDK works in your self-service environment. We'll walk through your use case, hardware setup, and integration options.

Book a demo→

Developer Guides