Every RFID tag read that matters is recorded as anDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/CodexaCP/DG_BACK/llms.txt
Use this file to discover all available pages before exploring further.
RfidScanEvent. Events are immutable, tenant-scoped, and designed to serve as the RFID evidence layer — the ERP never needs to know an EPC was involved. A single table covers all four warehouse modules (Items, Receipts, Shipments, Movements), and each record captures everything needed for audit, troubleshooting, and analytics: the raw and normalised EPC, the module, the document reference, the resolution outcome, the validation outcome, the operator, the device, and the timestamp of the physical read.
Submit a scan event
201 Created with the saved RfidScanEventDto including the system-assigned id and any resolved item linkage.
Request fields (CreateRfidScanEventDto)
How the read was triggered. Typical values:
RFID_SCAN, BARCODE_SCAN, MANUAL_ENTRY.The warehouse module context for this read:
Items, Receipts, Shipments, or Movements.Type of event being recorded. Examples:
TAG_READ, TAG_VALIDATED, TAG_REJECTED, TAG_NOT_FOUND.The EPC string exactly as read from the antenna or decoder.
The canonicalised EPC used for registry lookup. If omitted, the service derives it from
rawEpc.ID of the
HandheldDevice record that performed the read.ID of the
RfidTagRegistry row that was resolved for this EPC, if known at submission time.ID of the active tag assignment, if the read was tied to a specific document assignment.
Outcome of EPC-to-item resolution. Examples:
RESOLVED, NOT_FOUND, AMBIGUOUS_DUPLICATE, INACTIVE.Outcome of the operational validation check. Examples:
VALID, INVALID, SKIPPED, MISMATCH.ID of the resolved item, if EPC resolution succeeded.
Item number captured at the time of the read (for historical accuracy if item data changes).
Type of the warehouse document being operated (e.g.
RECEIPT, SHIPMENT, MOVEMENT).Document number being processed when the read occurred.
Line number within the document, when the read is tied to a specific line.
Location code at the moment of the read.
Bin code at the moment of the read.
Quantity associated with this read (e.g. units on the scanned pallet).
What initiated the read. Examples:
OPERATOR_TRIGGER, AUTO_SCAN, API_CALL.Device key captured at the time of the read.
E-mail address of the operator who performed the scan.
A client-supplied ID to group multiple related reads (e.g. all scans within one receiving session).
A client-supplied session identifier for the handheld application session.
How the tag was resolved (e.g.
TAG_REGISTRY, TAG_ASSIGNMENT).The RFID operating mode that was active at the time of this read (
Disabled, InquiryOnly, OperationalAssist, StrictValidation).The specific validation rule that was applied, if any.
UTC timestamp of the physical read on the device. If omitted, the server records the time of receipt.
Error detail when the read could not be resolved or validated.
Optional freeform JSON payload for SDK-specific metadata (signal strength, antenna index, reader firmware, etc.).
Example
Query scan events
Tenant view
RfidScanEventDto records scoped to the calling tenant.
| Query parameter | Type | Description |
|---|---|---|
module | string | Filter by warehouse module |
resolutionStatus | string | Filter by resolution outcome (RESOLVED, NOT_FOUND, etc.) |
validationStatus | string | Filter by validation outcome (VALID, INVALID, etc.) |
search | string | Free-text search across EPC, item number, and document number |
documentType | string | Filter by document type |
documentNo | string | Filter by exact document number |
correlationId | string | Filter by client correlation ID |
sessionId | string | Filter by client session ID |
fromUtc | datetime | Start of time window (inclusive) |
toUtc | datetime | End of time window (inclusive) |
errorsOnly | bool | When true, returns only events that have a non-null errorMessage |
page | int | Page number (1-based) |
pageSize | int | Records per page |
Export to Excel
.xlsx file containing all matching events. Useful for compliance reporting and offline analysis.
The response has Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet and a filename of the form rfid_scan_events_YYYYMMDD_HHmmss.xlsx.
Admin view (Supreme)
Document scan commit
Before the handheld posts individualRfidScanEvent rows, it can commit a batch of scans atomically against a specific document. This endpoint is designed for receiving and shipment workflows where all tag reads for a document are collected in a session and committed together.
Commit document scans
Type of the document being operated (e.g.
RECEIPT, SHIPMENT).Document number being processed.
Warehouse module context:
Items, Receipts, Shipments, or Movements.Client session identifier to link these scans to a handheld session.
Client correlation ID for grouping related commit calls.
Array of scan items. Each element (
RfidDocumentScanItemDto) supports:| Field | Type | Description |
|---|---|---|
rawEpc | string? | Raw EPC as read from the antenna |
normalizedEpc | string? | Canonical EPC |
documentLineNo | string? | Line number within the document |
itemId | guid? | Expected item ID |
itemNo | string? | Expected item number |
quantity | decimal? | Quantity for this scan |
deviceKeySnapshot | string? | Device key at the time of the read |
handheldDeviceId | guid? | ID of the reading device |
RfidDocumentScanCommitResultDto):
| Field | Type | Description |
|---|---|---|
documentType | string | Document type that was processed |
documentNo | string | Document number that was processed |
totalScans | int | Total number of scans submitted |
committedCount | int | Number of scans successfully committed |
skippedCount | int | Number of scans skipped (e.g. duplicates) |
lines | array | Per-scan result (RfidDocumentScanCommitLineDto) with index, normalizedEpc, committed, and message |
Get document evidence
| Query parameter | Required | Description |
|---|---|---|
documentType | ✓ | Document type |
documentNo | ✓ | Document number |
module | ✓ | Warehouse module |
RfidDocumentEvidenceDto):
| Field | Type | Description |
|---|---|---|
documentType | string | Document type |
documentNo | string | Document number |
requiresEvidence | bool | Whether the active policy requires RFID evidence for this document |
evidenceSatisfied | bool | Whether the evidence requirement has been met |
committedScanCount | int | Total number of committed scans on file for this document |
committedEpcs | array | List of EPC strings that have been committed |
Operational validation (pre-flight)
Before committing a warehouse operation — for example, confirming a receipt line or completing a shipment pick — the handheld can ask Dragon Guard to validate a single EPC against the expected operational context.Single EPC validation
Warehouse module context:
Items, Receipts, Shipments, or Movements.The raw EPC as read from the antenna.
The canonicalised EPC. At least one of
rawEpc or normalizedEpc must be provided.Type of the warehouse document being validated against.
Document number being processed.
Line number within the document.
Expected item ID — used to check whether the scanned EPC matches the expected item.
Expected item number (alternative to
itemId).Location code where the operation is expected to take place.
Bin code within the location.
Quantity expected for this tag read.
ID of the reading device.
Device key at the time of the read.
E-mail of the operator submitting the validation.
Client correlation ID to link this validation to a session or batch.
Client session identifier.
Operating mode the handheld is currently running under (used for policy resolution).
Specific validation rule to apply, if overriding the policy default.
What triggered the validation request.
Optional SDK metadata JSON.
Response (RfidOperationalValidationResultDto)
Whether the validation call itself succeeded (not the same as
isValid).Whether the EPC was found in the
RfidTagRegistry.Whether the resolved tag matches all expected operational attributes (item, location, quantity).
Whether the active policy requires blocking the operation based on this result.
Whether the active policy permits manual fallback after this validation outcome.
Whether the active policy permits barcode fallback after this validation outcome.
The module that was evaluated.
The operating mode that was applied.
EPC resolution outcome (
RESOLVED, NOT_FOUND, AMBIGUOUS_DUPLICATE, INACTIVE).Validation outcome (
VALID, INVALID, SKIPPED, MISMATCH).How the tag was resolved (
TAG_REGISTRY, TAG_ASSIGNMENT, etc.).The specific rule that produced the validation outcome.
Human-readable explanation of the outcome.
Echo of the client-supplied correlation ID.
Full resolved tag context when
isResolved = true.Batch validation
items array where each element is an RfidOperationalValidationRequestDto. Batch size is validated server-side; submitting more than 100 items returns 400 Bad Request.
RfidValidateBatchResultDto):
Number of items submitted.
Number of items where
isValid = true.Number of items where
isValid = false.Number of items where the policy requires blocking the operation.
true if at least one item in the batch has shouldBlock = true. The handheld should halt the operation if this flag is set and the module is in StrictValidation mode.Per-item array of
RfidValidateBatchLineResultDto, each containing index, normalizedEpc, and a full RfidOperationalValidationResultDto.Audit field coverage
EveryRfidTagRegistry row and every RfidScanEvent record carries a complete audit trail:
| Field | Present on | Description |
|---|---|---|
createdAtUtc | Tags, Events | UTC timestamp of record creation |
createdBy | Tags, Events | E-mail of the operator or system that created the record |
updatedAtUtc | Tags | UTC timestamp of the last update |
updatedBy | Tags | E-mail of the operator or system that performed the update |
Tag batch orders (Supreme)
For tenants that need physical ZPL labels printed before commissioning tags in the registry, Supreme provides a tag batch ordering workflow.| Method | Endpoint | Description |
|---|---|---|
GET | /api/supreme/companies/{companyId}/rfid/tag-batches | List tag batch orders for the tenant |
POST | /api/supreme/companies/{companyId}/rfid/tag-batches | Request a new batch of physical RFID tags to be printed |
PATCH | /api/supreme/companies/{companyId}/rfid/tag-batches/{orderId}/fulfill | Mark a pending batch order as fulfilled (completed) |
| Status | Meaning |
|---|---|
PENDING | Batch has been requested and is awaiting processing |
PROCESSING | EPCs are being generated or labels are being prepared |
COMPLETED | All EPCs have been issued and ZPL strings are available |
CANCELLED | Batch was cancelled before completion |
Immediate EPC issuance
tag-batch endpoint (as opposed to tag-batches) generates EPCs immediately and returns ZPL label strings suitable for direct submission to a Zebra label printer. Use this for on-demand commissioning at the point of packing or receiving.
Tags are pre-registered in the registry with status = AVAILABLE and the response includes ZPL strings with ^RFW commands so the RFID chip is programmed during the print pass (TCP port 9100).
Request body (RfidTagIssuanceRequestDto):
| Field | Type | Description |
|---|---|---|
batchReference | string? | Optional reference label for this issuance |
remarks | string? | Free-text notes |
lines | array | Array of RfidTagIssuanceLineDto items (see below) |
RfidTagIssuanceLineDto):
| Field | Type | Description |
|---|---|---|
itemId | guid? | Item to associate with the generated tags |
itemNo | string? | Item number (resolved within the tenant if itemId is null) |
objectType | string | Tag object type. Default ITEM_UNIT. One of ITEM_UNIT, CASE, PACK, PALLET, BIN, LOCATION, ASSET |
quantityPerTag | decimal | Quantity each tag represents. Default 1 |
tagCount | int | Number of tags to generate for this line (1–200) |