POS Extensions / Developer Changelog

POS Extensions now supports
a "UI-less" background extension target

The new target pos.app.ready.data runs for the entire POS session and can watch POS events, store data, and call non-visual APIs without rendering anything on screen. Extensions that do something other than "show something on the register screen" are finally officially supported.

On this page
  1. What's actually new (understand in 30 seconds)
  2. How it works: the POS session and background target lifecycle
  3. 3 intended use cases
  4. How to use it: subscribing to events is almost one line
  5. List of supported events
  6. Comparison with existing UI targets
  7. 5 points developers should know
  8. 3 use cases for your business
  9. One-line summary for proposals

1What's actually new

Until now, POS UI Extensions assumed you would render "a tile, a modal, or some otherUI somewhere on the screen."
The new target pos.app.ready.data renders no UI at all andkeeps running from the start to the end of the POS session, giving you a behind-the-scenes execution slot.

Before: UI targets

They only run when rendered on a UI surface staff can see, such as a tile or modal. While they aren't displayed, your logic can't run either.

New: background target

pos.app.ready.data stays resident for the entire POS session. It can watch POS events and run background logic without any UI.

2How it works: the POS session and background target lifecycle

POS session starts Session ends pos.app.ready.data = keeps running for the entire session (no UI rendering) transactioncomplete Detect transaction completion cashtrackingsessionstart Cash tracking session started cashtrackingsessioncomplete Cash tracking session completed Each time an event fires, the addEventListener handler is called. Nothing appears on the staff's screen.
In web terms, a a Service Worker-like roleis a close analogy: an execution slot with no screen that handles only event-driven, behind-the-scenes work. You can now separate "extensions that draw on the POS screen" from "extensions that react to POS events."

3Three intended use cases

The article explicitly lists the following three use cases for the background target.

Event monitoring

Subscribe in real time to POS events such as transaction completion and the start or completion of cash tracking sessions.

Data storage

Data storage based on the monitored events. You can keep records without any UI interaction.

API

Calling non-visual background APIs

You can call background APIs that don't render UI. See the official app background target documentation for details on supported APIs.

4Usage: subscribing to an event is almost one line

All you do is call shopify.addEventListener() to subscribe to POS events. It reads just like the web-standard addEventListener.

// Inside an extension for the pos.app.ready.data target shopify.addEventListener('transactioncomplete', (event) => { console.log('Transaction complete', event); });
The handler is passed an event object. From there you receive transaction details and feed them into your background processing (the article doesn't document the event's contents; check the official documentation).

5Supported events

Event nameWhen it firesExample use
transactioncomplete When a transaction (payment) is completed Follow-up processing or record-keeping triggered by a sale
cashtrackingsessionstart When a cash tracking session starts Detecting and recording register opening
cashtrackingsessioncomplete When a cash tracking session is completed Detecting and recording register close-out

Note: the article lists only the three events above (it says "Supported events include," so it may not be exhaustive). See the official app background target documentation for the latest list and best practices.

6Comparison with traditional UI targets

AspectUI targets (traditional)pos.app.ready.data (new)
UI rendering Yes Renders to tiles, modals, etc. No Renders no surfaces at all
Execution lifetime While the UI is visible The entire POS session stays resident
How it starts Staff action (tapping a tile, etc.) Starts automatically when the session begins
Main role Displaying information and interacting with staff Watching events, saving data, and calling non-visual APIs

75 points developers should know

.data

1. The target name is pos.app.ready.data

Specify this as the extension's target to get a background execution slot. The ".data" suffix signals that no UI is rendered.

2. The lifecycle is "the entire POS session"

Unlike UI extensions launched by staff actions, it stays alive for the whole session. Design your listener registration and state handling with an always-on process in mind.

3. The interface is shopify.addEventListener()

A web-standards-style event listener API. Subscribe with an event name string ('transactioncomplete', etc.) and receive the event in your handler.

4. Only 3 events are documented so far

transactioncomplete / cashtrackingsessionstart / cashtrackingsessioncomplete. It starts with the core register-operations events: transactions and cash tracking.

Docs

5. Detailed specs aren't in the article = you'll need the docs

The contents of the event object, the list of background APIs you can call, supported POS / API versions, and how it combines with UI extensions arenot covered in the article. Be sure to check the official app background target documentation and best practices before implementing.

83 use cases you can apply to your business

POS
USE CASE 1

Automatically syncing store data whenever a transaction completes

Problem
Passing in-store sales data to external systems (CRM, loyalty platform, analytics, etc.) relies on batch syncs or manual staff work, causing delays and gaps.
Approach
Stay resident with pos.app.ready.data and subscribe to transactioncomplete. Receive the event on every completed transaction and trigger downstream processing.
Impact
Capture transactions in near real time with zero staff actions and zero UI. Register operations don't have to change at all.
Tech notes
The article doesn't say what transaction data the event object includes. Check the app background target documentation before implementing, including whether and how you can send data externally.
¥ Open → Close
USE CASE 2

A cash tracking log that automates register open/close records

Problem
In multi-store operations, records of when registers were opened and closed are left to each store's handwritten notes or spreadsheets, so headquarters can't see what's actually happening.
Approach
Subscribe to cashtrackingsessionstart / cashtrackingsessioncomplete in the background and store the start and completion of cash tracking sessions as data.
Impact
Open/close events are recorded automatically, laying the groundwork for cross-store operational visibility and audit readiness. No extra staff training needed.
Tech notes
The article doesn't detail fields like amounts included in the events. The specific APIs for storing data (what you can write to and how) also need to be confirmed in the docs.
Tile UI extension + background Design with a clear division of roles
USE CASE 3

Redesigning an existing POS app by separating its "always-on logic" from the UI

Challenge
In an existing POS UI Extensions app, processing that should run behind the scenes (logging and monitoring) can only execute when staff open the tile, so runs get missed.
Approach
Refactor by moving the monitoring and logging logic to pos.app.ready.data, letting the UI extension focus purely on display and interaction.
Impact
Solves the "it doesn't run if staff forget to open it" problem. With UI and background responsibilities separated, the extension's design can be organized much like a web app (UI + Service Worker).
Technical notes
The article doesn't say whether it can be combined with UI targets or how to share data between them. Review the app background target documentation, including best practices, before starting.

9One-line summary you can use in a proposal

"POS Extensions adds an always-on slot that renders no UI pos.app.ready.data .
You can subscribe to transaction-completion and register open/close events with addEventListener,
and run background processing like logging and integrations with zero staff interaction."