Reference
Use this page when you need to look up a My-Scan API contract, basket behavior, configuration mechanism, or event integration. It points to the documentation that owns each detail rather than repeating specifications that can change independently.
If you are new to My-Scan, begin with Quick Start. For an explanation of why something happens during a shopping trip, use Business Flows; for step-by-step implementation, use the Developer Guides.
API contracts
The API specifications are the source of truth for exact operations, paths, request and response fields, authentication requirements, and error responses. APIs explains the capabilities and behavior behind them.
| API | Look here for |
|---|---|
| Shopper API | Creating and managing baskets, scanning items, finishing a trip, and retrieving parameters |
| POS API | Downloading a ticket to a POS or SCO and uploading the transaction result |
| Administration API | Finding and cancelling ongoing baskets |
For a first basket request and example responses, see Quick Start. Do not use an example in a guide in place of the API specification when implementing a client.
Basket and item lookup
| If you need to know... | Go to |
|---|---|
| What a basket contains, including items, totals, and promotions | APIs: Basket View |
| What the basket states mean and which operations are allowed | APIs: Basket States and Business Flows: Shopping Trip |
| How to add, remove, or change the quantity of an item | APIs: Order of Operations |
| How packaging or quantity prompts affect an item scan | APIs: Adding an Item and Business Flows: Item Scanning |
| How age verification or a rescan affects checkout | Business Flows: Age Verification and Rescan |
| How payment on a device differs from POS handover | Business Flows: Payment and POS Handover |
For exact field names, allowed values, and responses, check the applicable API contract.
Configuration lookup
| If you need to know... | Go to |
|---|---|
| Where Core Service parameters come from in Cloud or OnPrem | Configuration: Parameters |
| How tenant or store overrides are resolved | Configuration: Configuring for specific tenants and stores |
| How a Selfscanner retrieves and caches parameters | Configure a Selfscanner |
| Which settings are secrets and how the Core Service receives them | Configuration: Secrets |
| How tenant- and store-scoped CCC settings work | Configuration: Tenant Configuration and Store Configuration |
| Which feature flags and push topics are documented | Configuration: Feature Flags and Push Topics |
Configuration documentation describes the Core Service unless it explicitly identifies a client application. Do not assume that a Core Service parameter is also a device-managed setting, or that an Exit Unit MDM setting applies to a Selfscanner.
Events and integrations
- Architecture: Event Flow — how basket transitions, assistance, audit results, and analytics fit into the service flow.
- Configuration: Push Topics — documented outbound basket event and inbound Pub/Sub push endpoints.
- Consume Basket Events — how to subscribe to the Cloud basket-updated topic. It is a Pub/Sub topic, not an HTTP webhook.
- Integrations — the systems My-Scan works with, including identity, configuration, pricing, attendant, audit, analytics, POS, and payments.
- Operations — customer administration, analytics dashboards, and basket monitoring.
Device release, handheld status, and device commands belong to the separate Device Management Service and Scan&Go Device API, not the My-Scan Shopper API.
Developer Guides
Use these when you need a procedure rather than a lookup:
- Integrate a New POS
- Integrate a Payment Provider
- Configure a New Retailer
- Configure a New Store
- Configure a Selfscanner
- Add a New Parameter
- Consume Basket Events
- Testing & Test Tenants
Earlier app-specific documentation
The My-Scan folder also contains synced feature documentation for earlier client applications, including My-Scan 5 parameters, barcode definitions, and app failures and error messages. Consult those pages when working with the corresponding app generation.
These pages are not a substitute for the current Core Service API specifications. In particular, app failure/translation codes should not be presented as Core Service HTTP error contracts, and legacy barcode or parameter examples should not be assumed to apply to every client or deployment.