An API turns a tag read into an accounting operation
A reader can report the same EPC many times while a tagged object remains in the antenna field. Sending every raw read directly to an ERP creates duplicates and does not explain what actually happened in the process.
An integration layer controls devices, normalizes data, groups reads by time and zone, links EPC values to business objects and emits a stable event such as receiving, shipment, transfer or access.
The API contract should describe both successful processing and exceptions: an unknown tag, an unexpected item, a conflicting zone or temporary unavailability of the target system.
Five layers of a production integration
Separating device traffic from business logic makes the system easier to test, monitor and extend.
Reader
EPC, time, antenna and read parameters.
Edge service
Device management and one normalized data format.
Event
Deduplication, zone, object and process rule.
Exchange
REST API, webhook, queue or scheduled batch.
1C / WMS / ERP
Document, status, discrepancy and processing acknowledgement.
A technical read is not the same as a business event
The integration layer must preserve diagnostics while exposing a stable process-level contract.
Technical read
EPC, reader, antenna, timestamp, zone, session and diagnostic parameters.
Business event
Unique ID, operation type, object, source document, time and validation result.
Duplicate removal
Repeated reads are combined within the same zone and time window.
Process matching
The EPC is linked to an item, asset, pallet or vehicle and to the expected operation.
What to define in the API contract
Agree these points before development so that device behavior and accounting rules do not become mixed together.
- Event identifier and idempotent processing.
- Timestamp, timezone, reader, antenna and logical zone.
- EPC, TID when required, and the linked business object.
- Operation type, source document and expected object list.
- Accepted, rejected and warning statuses with machine-readable reason codes.
- Authentication, authorization, encryption and credential rotation.
- Retries, queue retention and behavior during network outages.
- Structured logs, metrics, alerts and a trace ID across systems.
Ways to connect the corporate system
The exchange method follows the required response time, outage tolerance and ownership boundaries.
HTTP API
Useful when the sender needs an immediate response: document found, event accepted or discrepancy detected.
Webhooks
The RFID platform pushes an event when it is formed. Acknowledgement, retries and a stable event ID are required.
Message queue
Decouples read speed from document processing and absorbs temporary target-system outages.
Batch exchange
Events are transferred in batches where real-time processing is unnecessary or access is restricted.
From event model to production launch
- Describe operations
List the accounting operations, source documents, zones and exception scenarios.
- Map the data
Agree identifiers, directories, ownership and the EPC-to-object relationship.
- Choose the device layer
Confirm LLRP, SDK or gateway support for every reader model.
- Define the contract
Document endpoints, events, status codes, security, retries and idempotency.
- Build a test stand
Use representative tags, reads, duplicates, unknown EPC values and target-system failures.
- Run a pilot zone
Compare RFID events with real operations and accounting documents.
- Add monitoring
Track reader health, queues, processing latency, errors and reconciliation.
- Scale by zones
Reuse the approved contract and keep zone-specific rules configurable.
LLRP does not replace an application API
LLRP standardizes reader control and radio operations. The application API carries processed events to 1C, WMS or ERP. A device protocol, an edge service and a business integration contract solve different problems and should remain separate.
RFID API questions
Is there one API for every RFID reader?
There is no single application API supported by every device. Some readers expose LLRP, while others use a vendor SDK or protocol. A middleware layer normalizes these interfaces into one event model.
Are LLRP and an RFID API the same thing?
No. LLRP controls readers and radio operations. An application RFID API delivers processed events to 1C, WMS, ERP or another business system.
Can RFID connect directly to 1C?
It can, but several readers and zones are usually more reliable through an intermediate service. It filters duplicates, buffers events during outages and keeps device drivers outside the 1C configuration.
What happens if 1C or WMS is unavailable?
A resilient design stores events in a local queue and retries after recovery. Stable event identifiers and idempotent processing prevent duplicate documents.
Is EPCIS required for an internal RFID project?
Not always. EPCIS is useful for standardized visibility-event exchange across systems or companies. A local project may use an agreed REST API or another internal contract.
Technical basis: official GS1 specifications and official 1C development documentation.
GS1 LLRP 2.0 · GS1 EPCIS · EPCIS 2.0.1 artefacts · 1C:Enterprise documentationNext step
Design the event model before developing the API
Describe the accounting system, reader models and operations. BizData will propose an exchange architecture and validate it in a pilot RFID zone.
