One JSON API for Every Language

Published: 18/09/2026

A platform team evaluating kiosk middleware usually asks the same first question: which language SDK does it ship? The better question is what the API contract is. Those two questions lead to very different integration projects.

A per-language SDK means a separate library for each stack, each with its own version, native dependencies, and release cadence. A JSON API means one contract that any application can call, whether it is written today in .NET or three years from now in something else.

The problem with per-language SDKs

Per-language libraries start to drift the moment the hardware catalog grows. A vendor adds a dispenser model and updates the Java binding; the .NET wrapper follows weeks later; the Python package is maintained by a different team and lags further behind. Each binding re-implements the same device logic, so every fix and feature has to land several times.

Native dependencies make the problem worse. A library that wraps a serial or USB driver ties the application to a platform architecture, complicates automated tests, and makes deployment harder than the rest of the stack. When a device driver changes, the application may need to be rebuilt and redeployed even when its own code did not change.

What an HTTP and JSON contract changes

With a JSON API, the device operations live behind one contract. A cash dispenser exposes readiness, dispense, purge, and reset; a document reader exposes a trigger and a result read; a SIM dispenser exposes an ICCID read, a dispense, and a reject. Every call returns the same response envelope with a status code, message, data, and errors.

That shape has practical consequences. A team already using HttpClient, RestTemplate, requests, or fetch does not adopt a new library or learn a new programming model. The same integration tests work whether the caller is a .NET service, a Python test harness, or a JavaScript front end. A device driver update inside the SDK does not force application rebuilds, and a new language on the team is not blocked on a vendor shipping a binding for it.

What this looks like in practice

On a kiosk, the SDK runs as middleware and serves the API locally. The application sends a request such as a readiness check or a dispense instruction, and reads back a JSON response. The examples in the SDK hub show the same two operations implemented in C#, Java, Python, and Node.js — the payloads and the error handling are identical, only the HTTP client differs.

Because the contract is text rather than a binary interface, it is also easy to inspect. A failed dispense can be reproduced with a single request from a terminal, and the error envelope tells the application and the support team the same thing.

Questions worth asking any kiosk vendor

Ask how a stack that is not on the supported list integrates, and whether the answer is "a REST API" or "a community binding." Ask what happens to the application when a device driver is updated. Ask whether an integration can be tested without the vendor's native library and hardware attached. The answers separate a platform that absorbs hardware change from one that forwards that change to every application team.

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