One JSON API. Any language.
Azimut SDK exposes the hardware inside a kiosk through a single JSON API. Your team keeps its stack — C#, Java, Python, Node.js — and calls one contract across every device model and deployment.
Integration path
Language-agnosticAzimut SDK · JSON API
One envelope · one contract · every device family
The integration surface
A kiosk application talks to devices through one contract
Each device family exposes named operations over HTTP: check whether the device is ready, ask it to do something, and read back what happened. A cash dispenser reports status, dispenses an amount, purges, and resets. A document reader triggers a scan and returns the captured fields and image. A SIM dispenser reads an ICCID, dispenses, or rejects a card.
Every call returns the same envelope, so error handling is written once and reused across devices. A status code of0000means the operation succeeded; anything else carries a message the application can log, retry, or surface to the customer. The SDK absorbs the vendor protocol underneath — serial, USB, or network — so changing a device model does not change your integration.
{
"code": "0000",
"message": "SUCCESS",
"data": null,
"errors": null
}Multi-language support
The same calls, whichever language your team uses
The API does not ship as a library per language, so there is no wrapper to find, version, or update when a device driver changes. These examples run the same two operations — check the dispenser, then dispense an amount — against a kiosk-local base URL.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
using System.Net.Http.Json;
using System.Text.Json;
using System.Text.Json.Serialization;
record ApiEnvelope(
[property: JsonPropertyName("code")] string Code,
[property: JsonPropertyName("message")] string? Message,
[property: JsonPropertyName("data")] JsonElement? Data);
var api = new HttpClient { BaseAddress = new Uri("http://localhost:8080") };
var status = await api.GetFromJsonAsync<ApiEnvelope>(
"api/hardware/cash-dispenser/check-dispenser");
if (status?.Code != "0000")
throw new InvalidOperationException($"Dispenser not ready: {status?.Message}");
var response = await api.PostAsJsonAsync(
"api/hardware/cash-dispenser/dispense-amount",
new { amount = "5000" });
var result = await response.Content.ReadFromJsonAsync<ApiEnvelope>();
if (result?.Code != "0000")
throw new InvalidOperationException($"Dispense failed: {result?.Message}");Device coverage
What sits behind the API
The SDK ships with drivers for the device families below, drawn from active deployments. Inventory is part of the same platform: cassette levels, reject bins, and cash bag positions come from the devices themselves rather than a count of transactions. When a project brings hardware that is not in the catalog, a driver is written once and every later deployment can use it.
Cash dispensing and recycling
Fujitsu F53, F56, and F510 cash dispensers and recyclers, and multi-cassette dispenser modules — dispense, purge, reset, and per-cassette note levels through one contract.
Fujitsu F53 integrationInventory and reconciliation
An append-only inventory journal tracks every note and stock item across cassettes, escrow, reject bins, cash bags, and vault positions, so replenishment and reconciliation work from live positions.
Inventory managementNote and cheque acceptance
MEI banknote validators and cheque acceptors surface note values, escrow, and fault state as JSON instead of serial or vendor-specific messages.
MEI SC Advance integrationReceipts, documents, and card issuance
Thermal receipt printers, document printers, and instant issuance modules are driven through the same API, with paper and stock state included.
Document printing workflowsIdentity and biometrics
Fingerprint readers, passport and ID scanners, and cameras return captured data and quality checks to the application through the API.
KYC and identity workflowsSIM and card dispensing
SIM dispensers and card dispensers expose availability, ICCID reads, dispensing, and reject-bin status for telecom and card issuance flows.
SIM issuance workflowsPayment terminals
PCI-compliant terminals from PAX, Verifone, and other vendors are addressed as devices in the same session as the rest of the kiosk.
PAX A50 integrationHow integration works
Your application keeps the business logic
The SDK runs as middleware on the kiosk and exposes the JSON API locally, so the application never needs to know which physical device is attached. It checks readiness before a session starts, keeps device state across the session, and reports what happened to the management layer.
That split is what makes the model work for platform teams and system integrators. You write the customer journey — identity checks, payments, disbursement, issuance — and the SDK owns the device lifecycle underneath. Swap the hardware model and the same API call still completes the transaction.
White-label the operations portal, run your own application on top of the SDK, or embed both into a product you already sell. The API contract stays the same.
Any stack
One JSON contract for .NET, JVM, Python, JavaScript, Go, PHP, and anything else with an HTTP client.
One device model
Dispensers, acceptors, printers, scanners, and terminals are addressed as devices in one session.
Faults in the flow
Status codes and readiness checks put device faults into normal application error handling.
Swappable hardware
A new model is a driver change inside the SDK, not an application rewrite.
Questions
Developer integration, answered
The short version: one JSON API, any language, no per-model library. The details below cover the questions integration teams ask most.