Integrating with your systems
QuickComm devices stream to the backend you configure. This is the shape of the system you build around them: ingest, recognition, your logic, your response — and the five seams that let one firmware serve any vertical.
7 min read
On this page
QuickComm sells hardware, not a data platform. The device streams to whatever endpoint you provision it with, and every decision after that byte arrives is yours: what a sentence means, who it is routed to, what gets created, what gets printed, what gets spoken back. Your models, your database, your business rules, your customers' data on your own infrastructure.
That is the whole reason this integration is possible. Because the device holds no business logic, the same flashed firmware serves a restaurant, a guard force, a hotel, a warehouse or a clinic. What changes is the server it talks to and the logic that server runs.
The shape of the system you build
DEVICE │ YOUR INFRASTRUCTURE
│
─── audio plane ──────────────┼──────────────────────────────────────
│
button held, MEMS mic │
16 kHz s16le mono PCM ────────┼──▶ ingest ──▶ your STT ──▶ YOUR LOGIC
│ udp · http · ws │
│ ▼
speaker · LAN printer ◀───────┼─────────────────────── YOUR RESPONSE
│ tts · queue · ESC/POS
─── fleet plane ──────────────┼──────────────────────────────────────
│
heartbeat, telemetry ─────────┼──▶ presence · health · version
incidents ────────────────────┼──▶ what broke, and on which build
commands, OTA ◀───────────────┼─── reboot · change mode · staged rolloutYou implement the boxes on the right. This documentation specifies the line down the middle exactly — every byte the device sends, every response it expects, and every timer it runs — so that the boxes on the right are ordinary software you already know how to write.
What you owe the device
Less than you would expect. A factory-flashed unit is happy with one mandatory endpoint and one transport, and everything else degrades gracefully.
| You implement | Why | Effort |
|---|---|---|
| A heartbeat endpoint | Presence. Without it the device runs but you are blind | An hour |
| One audio transport, matching the device's mode | The actual product | A day to a week, by mode |
| Incidents, commands and OTA endpoints | Fleet observability and remote recovery. Optional, and you will regret skipping them | A day |
| A downlink queue (modes B and C only) | How your logic speaks back | Part of the transport |
| The print bridge (only if you print) | Receipts, tickets, labels | An afternoon |
The five seams your product lives in
The hardware asks one question — someone spoke; what now? — and every vertical answers it differently. These are the seams where your answer plugs in.
| Seam | What you control | Where it lives |
|---|---|---|
| 1. Placement | What a device is: a table, a team, a person, a zone | The identity fields in the provisioning payload |
| 2. Language | Which language a unit is recognised in | Your recognition call, driven by the device's identity |
| 3. Understanding | What intents exist, what counts as urgent, what a phrase means | Your models and prompts |
| 4. Action | What gets created, who it routes to, what deduplicates | Your database and workflow |
| 5. Response | What the device says, prints or shows | Your downlink queue, agent or print payload |
Note what is not on that list: the audio path, the wire protocols, the fleet plane and the button. Those are the same for everybody, which is exactly why one firmware serves all of these.
The identity fields are a namespace you define
Every packet a device sends carries the same small set of identity fields. The device attaches no meaning to them and neither does the protocol — they are integers you provision and your server interprets.
| Field | The device treats it as | You can make it mean |
|---|---|---|
| property_id | An opaque required integer | A site, a building, a customer, a tenant, a vehicle |
| organization_id | An opaque integer, carried for convenience | The account this site rolls up to |
| team_id | An opaque integer | A crew, a shift, a floor, a zone, a queue |
| table_id | An opaque integer | A table, a bay, a bed, a workstation, a kiosk |
| user_id | An opaque integer | The person carrying the unit |
Where to go next
- 1The minimum server — exactly what you have to stand up, with a reference implementation.
- 2The page for the mode your device is in: push-to-talk streaming, request and response, or full-duplex agent.
- 3Building your business logic — eight worked verticals on the same firmware.
- 4Acceptance tests — twenty-seven pass/fail tests to run before a customer sees it.
Something wrong or missing on this page? Tell us.