Event schema
Stable event names, device ID, timestamps, payment reference, slot, and result fields.
Guides
Vending telemetry integration
How do I send vending telemetry to my own backend?
Send vending telemetry to your own backend by defining an event schema, choosing HTTPS webhook, HTTP API, or MQTT, adding device identity and retries, and testing one machine. QuLink can collect available machine-side data, but the backend, retention, and alert ownership stay with your team; field availability is confirmed on a sample.
Own backendWebhook / MQTTRetry designSample validation
Part of Machine Data Upload IoT Board for Self-Service Equipment
Integration parts
Four parts of a telemetry integration.
A reliable data path is more than a board. Define the payload, transport, failure behavior, and operational owner before the pilot.
Transport
HTTPS webhook, HTTP API, or MQTT depending on your platform and network policy.
Reliability
Retries, offline buffering, duplicate handling, idempotency, and reconnect behavior.
Security
TLS, device credentials, access control, rotation, and monitoring of failed deliveries.
Before you connect
Check these four integration points.
Device identity
Define a stable device ID, site ID, and machine mapping that your backend can trust.
Event fields and timestamps
Agree on required fields, time zone, event ordering, and optional fields per machine type.
Network and SIM policy
Confirm 4G coverage, data plan, APN, roaming policy, and whether local network fallback exists.
Backend ingestion
Prepare the endpoint, authentication, idempotency key, retention, and alert routing.
Pilot flow
From one machine to a reliable event stream.
Define the event set
Start with heartbeat, vend result, and one fault event rather than every possible field.
Choose the transport
Select webhook, HTTP API, or MQTT and agree on authentication and payload shape.
Implement retries
Define offline buffering, duplicate handling, backoff, and the timeout for each event.
Test one machine
Verify delivery, reconnect, duplicate events, alert routing, and data retention.
Where QuLink fits
Machine-side transport, not a closed data portal.
What QuLink can do
- Collect available machine events and send them to your own endpoint.
- Support HTTPS webhook, HTTP API, or MQTT where the project requires it.
- Define event payloads, device identity, retries, and offline behavior with your team.
- Keep the existing controller and payment path where the interface supports it.
What it does not replace
- A closed monitoring portal or mandatory SaaS subscription.
- Your backend application, dashboard, or data platform.
- Payment acquiring, settlement, or wallet balance.
- A guaranteed network or SIM coverage result.
Not the right fit if
- The machine exposes no usable data source.
- There is no backend endpoint or operational owner for the events.
- You need a complete analytics product rather than machine-side data transport.
Transport and data
What the integration needs to handle.
- Machine interface
- MDB events, serial/RS485, relay state, pulse input, sensor input
- Transport
- HTTPS webhook, HTTP API, or MQTT; TLS and credentials per project
- Reliability
- offline buffering, retries, duplicate handling, last-seen state
- Project mode
- telemetry pilot, own backend, dashboard integration, OEM data profile
FAQ
Vending telemetry integration questions.
Should we use webhook or MQTT?
It depends on your platform and network policy. Send the endpoint or broker, topic design, authentication, and expected event volume so the transport can be scoped.
What happens when the machine is offline?
The project can define buffering and retry behavior, but availability depends on the hardware profile and storage. This is confirmed in the sample.
How do we avoid duplicate events?
Use a stable event ID and an idempotency rule in your backend. Retry behavior and duplicate handling are defined during integration.
Can QuLink support TLS?
TLS and device credentials can be included where the board and firmware profile support them. The exact options are confirmed per project.
What should we test first?
Test one machine with heartbeat, one vend event, and one failure or reconnect case before adding more event types.
Project RFQ
Send a machine photo. We help identify the board, interface, and next test step.
Send the machine model, available data points, target endpoint or broker, event examples, and the failure behavior you need.
A good first message
If you are unsure about the exact interface, send what you have. Photos often answer more than a long spec.
- Machine type and target country
- Machine photo, board photo, or wiring photo
- Action after payment or API command
- Need data upload? expected quantity?
Fastest first step
- Send a machine photo
- Describe the action after API or payment
- Tell us if data upload is needed
Related use cases