NewStore has several methods that you can use to consume data from the platform. This document gives guidance and best practices on which services and features to use for your business needs.
Data is typically consumed for one of these purposes:
Track business trends and analyze performance, using Omnichannel Insights
See the current status and act on it, using operational reports
Give store teams visibility of their own performance, using the Associate App Sales Dashboard
Exchange data with third-party systems, using application programming interfaces (APIs), the Event Stream, and GraphQL
The sections below cover each of these, grouped by who uses them:
Headquarters (call center, operations, retail teams, some store managers, and executives): Omnichannel Insights, operational reports
Stores (store managers, store associates): Associate App Sales Dashboard
Service integrators and developers: APIs, the Event Stream, GraphQL
Everyone: data retention
Reporting needs for headquarters
Headquarters has two options, and they answer different questions:
Omnichannel Insights answers what is the trend? It is analytical and historical, and covers a rolling 15-month window.
Operational reporting answers what is the current status, and what do I do about it? It shows the latest state and is where you take action.
Omnichannel Insights
Omnichannel Insights brings all your retailer data into a business intelligence tool embedded in Omnichannel Manager. Use it to understand trends, assess the state of the business, and adjust your strategy based on what the data shows.
Insights appears in Omnichannel Manager under the Insights menu, which has two items: Explore and Reports.
Explore allows data creators to:
Search the data directly
Build dashboards for other users
Share those dashboards with others in the organization, either directly in Omnichannel Manager or via email
Reports allows data consumers to track and improve a specific metric.
Typically, an Explore user designs a report for a Reports user.
Insights covers a rolling 15-month window of data. Analysis reaching further back than 15 months is not possible in Insights. See Data retention.
Example: Understand trends in store fulfillment performance
Operations, data teams, and retail teams can use Insights → Explore → Template → Fulfillment to get a quick view of store rejection rates. For that, you can filter the report by one or more fulfillment locations. Optionally, make a copy of the template and adjust the report as desired.
Example: Track fill rate by stores to understand underperforming locations
A retail manager or store operations manager might want to adjust the number of fulfillments a given store can handle. To understand which stores have a higher fill rate (number of fulfillments completed compared to the number rejected), use Insights → Explore to compare Fill Rate across locations, and across how many associates are available to fulfill. This can provide an optimal number of fulfillments relative to the number of available fulfillment employees, which you can then adjust in Routing → Locations in Omnichannel Manager.
Example: Track email capture percentage by sale location
There might be a push for more email capture during store sales. This requires a metric to measure, a baseline of current capture rate, actions to take to improve the capture rate, and measurement to determine if the actions turned into a higher capture rate. You can do this from Omnichannel Insights by using the default Customer dashboard, or by creating a custom dashboard to track capture rate by location. Then perform the actions desired to improve the capture rate, and view the dashboard again to understand the impact.
Operational reporting
Operational reports allow you to understand the current status of events and act on them. They contain the latest information available to NewStore about omnichannel, point of sale (POS), and order management system (OMS) events, and they appear throughout Omnichannel Manager.
An operational report is available in one of two forms, depending on the report:
As a table displayed in Omnichannel Manager
As an export, which is the same report as a downloadable file rather than an on-screen view
Both draw on the same underlying data, so an export contains what the corresponding table shows.
Examples include the Sales → Orders table, or the Store Operations → Stock on Hand report.
Example: Track and process orders that are on hold
A call center representative might need to reach out to shoppers to ask what they want to do with an order that can only be partially fulfilled, or an Operations member might want to cancel all orders that are on hold due to an inventory availability issue. You do this from the On Hold Orders page in Omnichannel Manager. All orders that are placed on hold, and might require user action, appear in Sales → On Hold Orders.
Example: Track stock on hand for a specific store location
An Operations member might want to understand what NewStore believes is available in a given store, to place an order for more merchandise based on what is available in the store. You do this from Store Operations → Stock on Hand in Omnichannel Manager: select a store, a stock location, and an on-hand threshold.
Reporting needs for stores
Understand sales performance
The Associate App Sales Dashboard helps store employees understand their own performance and their store's performance. The dashboard displays what is occurring in the store for the current day. Where it is enabled, users access it from More → Sales Dashboard.
Integrators or administrators enable the Sales Dashboard in Associate App → Customizations, then inform sales associates and store managers where to find it. Optionally, enable it in the staging environment to test and validate the data before enabling it in production for associates.
Retrieving data as integrators and developers
NewStore provides three mechanisms for retrieving data programmatically. They are not interchangeable.
APIs are the source of truth. The Event Stream and GraphQL are secondary sources derived from platform activity, and neither is authoritative. When the data must be correct and current, use an API.
Mechanism | Use it for | Do not use it for | Source of truth | Data available |
|---|---|---|---|---|
APIs | Authoritative reads and writes, platform configuration, enriching an event with trusted data | Bulk historical extracts | Yes | Active transactional data. See Data retention |
Event Stream | Reacting to platform activity in near real time; feeding an enterprise resource planning (ERP) system, business intelligence (BI) platform, or backup solution | Reporting, or as an all-in-one disaster recovery tool | No | Rolling 60 days |
GraphQL | Enriching a received event with context when no API covers it | Reporting, scraping, or lookups | No | Rolling 60 days |
APIs
APIs allow two applications to talk to each other. For example, NewStore can inform an ERP system that inventory has moved from location A to location B. Because a feature takes less effort to deliver in an API than in the user interface, some configuration is available via API before it reaches Omnichannel Manager.
NewStore provides two categories:
Integration APIs let NewStore communicate with your retail ecosystem of partners.
Configuration APIs perform system-level setup, such as setting up a catalog. These sometimes offer the same functionality as Omnichannel Manager, for example the routing setup.
NewStore is migrating to a more modern generation of APIs via the Omnichannel API Explorer, which better documents the purpose, data models, and design of existing and new APIs. The Omnichannel API Explorer does not cover every API, so check both references.
Event Stream
The Event Stream provides a best-effort stream of events for actions that occur on the platform. Service integrators create streams of events based on a topic, such as refund_request.issued or inventory_count.items_counted.
Consuming the Event Stream correctly requires three things:
Assume at-least-once delivery. The platform can replay events to ensure it eventually sends them all, so the same event can arrive more than once. Your integration needs middleware that handles duplicates.
Allow for publishing delay. NewStore usually publishes an event within seconds of the change, but publishing can take up to 15 minutes.
Treat events as a trigger, not as truth. An event tells you something happened. Where you need the authoritative state, follow up with an API call.
Retention is a rolling 60 days. That window exists to absorb downstream failures and lag, giving you time to recover your systems. It is not a data store: consume events in real time rather than relying on the window in normal operation.
Typical Event Stream use cases:
Streaming events from NewStore to your ERP system
Streaming events from NewStore to your BI platform
Streaming events from NewStore to your backup or disaster recovery solution
Creating a temporary integration to recover data from an outage, where the data is not older than 60 days
Do not use the Event Stream for:
Reporting, or any query spanning more than 60 days
An all-in-one disaster recovery tool
GraphQL
GraphQL takes the Event Stream and temporarily stores the data so it can be retrieved on request. It exists to supplement a received event with additional information a third-party system needs.
Like the Event Stream, GraphQL is a secondary source and is not a source of truth. It is eventually consistent, so data appears there later than in the originating system. Assume its data lifetime is coupled to Event Stream retention. Prefer an API over the generic GraphQL interface wherever one exists.
Typical GraphQL use case:
Enriching an Event Stream event with additional data, such as adding order information to a shipping event. For example, looking up order data when the Event Stream emits a
payment_account.amount_refundedevent.
Do not use GraphQL for:
Scraping a non-specific set of Event Stream data, such as looking up all refunds for the past six months
Generating reports
Querying as a lookup table, for example looking up an order ID by item code or stock keeping unit (SKU)
Example: Send data to an ERP system from NewStore
Create an Event Stream integration in NewStore and subscribe to that stream from the ERP system. This ensures the ERP system is aware of all POS activity on the platform.
When you need further context, such as additional payment data on receiving an order event, call a RESTful API rather than GraphQL, because APIs are the source of truth. Use GraphQL only where no API covers the data, and account for its eventual consistency: there is a delay between the change in the source system and its appearance in GraphQL.
Data retention
How long data remains available depends on which service you retrieve it from. Each service has its own retention policy, and they are independent of one another.
Data source | Retention | Notes |
|---|---|---|
Transactional systems (APIs, operational reports and exports) | Records created from 2018 onward | Records created before 2018 are archived and no longer returned. See Archived transactional data |
Event Stream | Rolling 60 days | The window exists for recovery, not storage. See Event Stream |
GraphQL | Rolling 60 days | Data lifetime is coupled to Event Stream retention. See GraphQL |
Insights and analytics data | Rolling 15 months | Data older than 15 months is not available for analysis or reporting. See Omnichannel Insights |
The transactional archiving policy does not override or change the retention policies of the other services.
Archived transactional data
Transactional data created before 2018 has moved out of active transactional systems into an archived storage layer. This keeps active datasets smaller, which helps core systems stay responsive and reliable.
Archived transactional data is:
Retained and not deleted
Securely stored for compliance and historical purposes, in line with applicable legal and regulatory requirements
Removed from active operational datasets
NewStore applies this approach consistently across all tenants and environments.
Archived data cannot be reached through standard channels
Pre-2018 transactional records are not returned by:
Standard transactional APIs, for example Orders, Payments, or Cart
Operational user interfaces that rely on those APIs
Operational reports and exports, which read from active transactional sources
To obtain archived records, request them from support.
Because these channels all read from the same active data, the effect is consistent across them. If the Orders API does not return a pre-2018 order, that order does not appear in the related operational views, tables, or exports either.
Request archived data
If you need access to pre-2018 transactional records, raise a retrieval request through NewStore Support.
Include the following in your ticket:
Tenant or business identifier
Relevant time range
Required data type, for example orders or payments data
NewStore handles requests through the standard support process. Fulfillment depends on feasibility and on the applicable retention policies.