Every integration conversation about secQR eventually splits in two. One half faces the packaging line: printers, label vendors, work orders, batches that must ship tonight. The other half faces your business systems: the ERP or WMS that knows what was made, the CRM that knows who sells it, the BI stack that reports on all of it.
The two halves run at different tempos and fail in different ways, so we treat them differently. This piece walks the whole path in the order an integration engineer will meet it.
The line side works in batches
Code generation starts with a work order. A production run is planned for a quantity, the run requests that many codes, and secQR generates them inside your controlled environment as a print-ready file for whatever printer and label vendor you already use. No secret is printed on the pack. The printed code is a pointer, and the record it resolves to stays on the server side, which is why a photograph of a genuine code buys a counterfeiter so little.
This shape matters on the shop floor. The line never waits on a network call per label. Codes are generated ahead of the run, applied at line speed, and reconciled afterwards: which codes were applied, which were wasted, which rolls were scrapped. Waste reconciliation sounds like bookkeeping until the first time a scrapped roll surfaces in a market you never shipped to.
The systems side speaks REST
On the other side sits your ERP or WMS. The REST API covers the operations those systems care about: request a batch against a work order, query the state of a code or a batch, change state (activate, suspend, revoke), and pull scan events for a time window. Each connected system authenticates with its own credential and its own scopes, and every call is logged, because the integration surface is itself part of the audit trail.
Treat state changes with respect. Revoking a batch is an operational act with consequences in the field, so we require an explicit reason code on every revocation and we record who asked. Your change-management process can hang off that record directly.
File exchange is unglamorous and often right
Integration teams sometimes apologise for asking about file exchange, as if a scheduled CSV were an admission of failure. We take the opposite view. A nightly drop of scan events into a location your ERP or WMS already watches can be live in days. It uses skills every operations team has, it survives vendor churn on either side, and it is easy to inspect when a number looks wrong. The API is the better surface for stateful operations, and most deployments grow into it. Starting with files gets evidence flowing while the API project clears procurement.
A CSV that arrives on time beats an API that is still in procurement.
Webhooks carry the alerts
Suppose a code generated for one territory starts scanning in a port city two borders away. That event is only useful if it reaches a person who can act within the hour, and that person does not live in a dashboard.
Webhooks push events to the systems your teams already work in: a case in the CRM for the brand-protection lead, a ticket for quality when a batch shows a duplicate cluster, a message to the distributor manager when scans cross a boundary they should not. You subscribe by event type and severity, so routine telemetry stays in the analytics store and only actionable events travel.
Deliveries retry on failure and carry a stable event identity, so a receiver can process a repeat without opening a second case. Build your consumer to be idempotent from the first day. Every webhook consumer learns this lesson eventually, and it is cheaper to learn it before the first duplicate alert wakes someone at 2 a.m.
Where secQR sits in the stack
secQR is product intelligence and authentication infrastructure built as an application on the KEZEL® platform, and the integration surface inherits its shape from that fact. KEZEL's rule is move the work, not the data: policies define the boundary, workflows travel to the data, intelligence runs inside, and results are released under policy. For an integration engineer the practical consequence is symmetry. Every surface described above behaves the same whether the platform runs in our multi-tenant cloud, in a private cloud under your keys, or on-premises inside your own data centre.
The order of work, then. Generate against a work order and print. Land scan events by file into the systems that already run your operation. Wire the two or three webhooks your response teams will act on. Bring up the REST API for state changes once the operational owners are named. That last clause is the real first step: decide, before any alert fires, which team owns the response when a scan comes back flagged.