Applications
My-Scan Core Service is one part of a larger family of client and companion applications. Some are direct API clients of the Core Service; others support the shopping journey without calling it. This page distinguishes those relationships.
This is an overview. Application-specific pages can provide the additional detail called for in the applications epic: Purpose, Deployment, Authentication, Authorization, Configuration, Parameters, Secrets, Push Notifications, APIs used, and Supported scenarios. Those details should be documented per application rather than assumed to be the same across clients.
| Application | Direct Core Service client? | What it is | Where to learn more |
|---|---|---|---|
| Selfscanner App | Yes | The mobile/handheld app a shopper uses to scan and check out | Configure a Selfscanner |
| POS Client | Yes | The POS or self-checkout client that receives a basket for payment | POS API |
| Customer Management Portal | Yes; Core Service also calls it | Staff-facing customer and basket administration | Operations: Customer Management Portal |
| Attendant App | Yes (Cloud only) | The staff-facing app for basket monitoring, assistance, and rescan | Architecture: Event Flow |
| Entrance Unit App | No (indirect) | The in-store kiosk that hands out and accepts back handheld scanners | Entrance Unit overview |
| Exit Unit App | No documented direct integration | An Android app displaying a store-specific QR code for exit verification | Exit Unit overview |
| Device Management Portal | Not established | Administrator-facing device-management interface named in the applications epic | Device Management Service |
| MDM | No (indirect) | Third-party tooling that provisions and configures the physical devices | Exit Unit MDM configuration |
Selfscanner App
What is it? The mobile or handheld app a shopper uses to scan items and check out — the primary, customer-facing client of My-Scan.
How does it relate to Core Service? It's the main consumer of the Shopper API: starting and continuing a basket, adding/removing/updating items, checking prices and promotions, and finishing (checking out) — essentially every Core Service endpoint except the internal maintenance, dynamic-EOT, and test-only controllers. At startup it fetches its configuration from the parameters endpoint (GET v3/parameters) and caches it locally, since parameters are treated as static per session — see Configure a Selfscanner and Parameters.
Which flows or APIs are involved? The full basket lifecycle described in Business Flows and API: Shopper API. On managed handhelds, device status and commands are handled separately through the Device Management Service.
Where can details be found? Configure a Selfscanner, Add a new parameter, Barcode Definitions.
POS Client
What is it? A point-of-sale (POS) or self-checkout (SCO) client where a shopper can pay for a My-Scan basket instead of paying on the scanning device.
How does it relate to Core Service? It consumes the POS API. The POS downloads the ticket for payment and uploads the transaction result afterward. “POS Client” describes the client in this integration, not an application implemented by the My-Scan Core Service.
Which flows or APIs are involved? POS Handover and the POS API.
Where can details be found? POS Handover, Integrations: POS, and Integrate a New POS. Deployment and client-specific configuration depend on the POS implementation.
Customer Management Portal
What is it? A staff-facing portal for searching, viewing, and managing self-service customers and their shopping activity.
How does it relate to Core Service? In cloud deployments, Core Service calls customer-management endpoints to look up, register, or block customers. The portal also uses Core Service's Administration API to view and cancel ongoing baskets. On-prem deployments use a different customer-service integration.
Which flows or APIs are involved? Customer Identification, Abandoned Trips, and the Administration API.
Where can details be found? Operations: Customer Management Portal describes the Core Service integration and how staff access the portal through the Hii Retail Console.
Attendant App
What is it? The staff-facing app used to monitor self-scan baskets and handle in-flow assistance and control events — age verification, flagged-item control, and rescans. Two generations exist:
- MyAttendant — the My-Scan-specific app, used for the on-prem environment, tied to the rescan-confirmation flow and the Rescan Service.
- HiiRetail Attendant App (HiiAttendant v2) — used in the cloud environment, backed by the Hii Retail Basket Audit Evaluation Service (BAES) instead of the Rescan Service, and used more broadly across self-checkout products, not just My-Scan. It's replacing MyAttendant.
How does it relate to Core Service? Core Service publishes basket-lifecycle and assistance events for the Attendant app (a BasketUpdated event on basket transitions, and assistance/control requests such as age verification or a flagged item), and receives control-resolution results back asynchronously once staff act on them. This integration is Cloud-only today — in the OnPrem host environment these are no-op, since OnPrem still relies on the MyAttendant-facing flow instead.
Which flows or APIs are involved? Age Verification and the rescan-related steps of Rescan for event publishing; rescan determination and results also flow through the public loss-prevention APIs (Basket Evaluation API, Basket Audit Result Ingestor API). See Architecture: Event Flow for how these events fit into the wider request/event model.
Where can details be found? Integrations: Socket.IO describes the underlying publish/subscribe channel; the Attendant app itself is maintained outside the My-Scan clan and isn't separately documented on this portal today.
Entrance Unit App
What is it? The kiosk application installed at a store entrance that a shopper interacts with to be handed a handheld scanner from a scanner wall, and to return it at the end of a trip. The documented HiiRetail Scan&Go Entrance Unit is a web application run in Zebra Enterprise Browser.
How does it relate to Core Service? Indirectly. The Entrance Unit App doesn't call the My-Scan Core Service — it registers as its own client and talks to the Scan&Go Device Management API, which handles device/cradle/wall state. Its contribution to the My-Scan flow is upstream of Core Service: it hands the shopper the physical device that runs the Selfscanner App.
Which flows or APIs are involved? Not part of a Core Service business flow directly; see the Scan&Go Device API for device-handout and return operations.
Where can details be found? Entrance Unit overview and setup. The Entrance Unit App is maintained as part of the Scan&Go/device-management ecosystem, not the My-Scan Core Service codebase.
Exit Unit App
What is it? An Android application deployed to a store device that displays a fullscreen, store-specific QR code. Customers scan the code for exit verification as they complete their self-scanning shopping journey. It is distinct from the Entrance Unit App, which handles handheld-scanner handout.
How does it relate to Core Service? The Exit Unit supports the wider shopping journey, but its documentation does not establish a direct integration with the Core Service's Shopper, POS, or Administration APIs. Do not treat the QR-code display as a Core Service endpoint or as a POS ticket-handover operation.
Which flows or APIs are involved? The app displays a dynamically generated QR code and refreshes it before expiry. Its documented dependencies include MDM-delivered device and store configuration, OCMS authentication, and store-scoped CCC settings for appearance. It can continue displaying its last valid QR code during a network interruption. See the QR Code Display and CCC Configuration pages for those app-specific behaviors.
Where can details be found? Exit Unit overview, features, and Settings & Configuration.
Device Management Portal
What is it? The administrator-facing device-management interface named in the applications epic. It is distinct from both the backend Device Management Service and the MDM tooling used to provision devices.
How does it relate to Core Service? Device administration is separate from Core Service's basket lifecycle. A direct Core Service integration for this portal has not been established in the available documentation.
Which flows or APIs are involved? The Device Management Service documents an Admin Operations API for listing and maintaining handheld scanners and entrance units. The portal's specific implemented features and API usage still need confirmation.
Where can details be found? See Device Management Service for the documented backend operations. A portal-specific reference should be added when its implementation is confirmed.
MDM (Mobile Device Management)
What is it? Third-party device-management tooling (for example SOTI) used to deploy and configure store devices, including handheld scanners, Entrance Units, and Exit Units. The settings delivered depend on the application.
How does it relate to Core Service? Indirectly. MDM provisions devices and applications; it does not call a Core Service API. A managed Selfscanner may use its configuration when connecting to Core Service, but that is not true of every managed app. In particular, Exit Unit receives OCMS registration and authentication settings, store and workstation identifiers, and a language setting through MDM. Its appearance settings come from store-scoped CCC configuration. Exit Unit has no documented direct Core Service integration.
Which flows or APIs are involved? Device provisioning precedes an application's own operations; it is not itself a Shopper API flow. See each application's documentation for its API and configuration dependencies.
Where can details be found? Exit Unit App: MDM configuration lists its managed-configuration keys, while Exit Unit CCC configuration covers its appearance settings. Entrance Unit setup documents that application's separate setup.