{"title":"Bring external data into POS","slug":"bring-external-data-into-pos","url":"https://support.storeconnect.com/articles/bring-external-data-into-pos","url_markdown":"https://support.storeconnect.com/articles/bring-external-data-into-pos.md","subtitle":null,"summary":"Show data from another system at the register, such as stock in an external warehouse or a carrier\u0026#39;s delivery dates. Use a relay page on your own store so credentials stay off the device.","type":"Help_Documentation","video_url":"","keywords":"external data at POS, third party integration, external inventory, 3PL, third party logistics, network inventory, marketplace stock, gift card balance, stored value lookup, warehouse stock, delivery availability, carrier lookup, API from POS, apex rest, relay page, broker page, api tag, special order shipping, credentials, POS integration","last_modified":"2026-09-17T05:42:27+0000","body_markdown":"Staff working in a store sometimes need information that is not kept in your system. For example, whether a supplier or a third-party warehouse has an item, what a carrier can actually deliver to this postcode and when, or other third-party sourced information.\n\nYou can bring this kind of data through to your store, to save staff members manually chasing the info or having to phone someone.\n\nYou can use a Liquid template to render this info in a POS view and make it available to staff.\n\n## Use cases\n\n-   **Third-party inventory.** A special order is worth taking only if the item can be sourced. A view on the product record can ask a supplier's or distributor's system what is available, and show it beside the store's own stock, so the operator commits to a date they can meet. See [Process special orders at POS](processing-a-special-order).\n-   **Third-party logistics.** Where fulfillment sits with a 3PL, the register can ask the warehouse what is on hand, whether an order has been picked or dispatched, and what the tracking reference is, rather than routing the question through the back office while the customer waits.\n-   **Inventory across a network.** Where stock is held in more than one system, a view can bring together what the local outlet has, what other StoreConnect stores and locations hold, and what is committed on marketplaces and other channels, so the answer to \"can I get this\" reflects the whole network rather than one shelf.\n-   **Delivery detail.** The delivery step knows the address, so a view can ask a carrier or delivery service which dates are genuinely available for that outlet and destination, and let the operator pick one, instead of promising a date the business cannot meet.\n-   **Third-party gift cards and stored value.** Where gift cards are issued on an external platform rather than as StoreConnect vouchers, a view can look up a card's balance and present it at the counter, so staff can answer a balance query without a separate terminal or a phone call.\n-   **Service and entitlement lookups.** A view can check an external record, such as a warranty, a license, or a membership held elsewhere, before the sale completes.\n\n## Keep credentials off devices\n\nPOS views and supporting scripts are delivered to every register, so anything written into a view is readable on the device. However, you don't want sign-in credentials, API keys or secrets in a published view.\n\nTo avoid this, use a relay page. This is a page on your own store that the register can call, which does the authenticated work server-side (hidden).\n\n1.  The POS view calls a page on the store's own origin.\n2.  That page uses the Liquid [api tag](api-tag-reference) to call the external service from the server, where the credential is held in store configuration rather than in the template that ships to devices.\n3.  The page returns the result, and the view renders it.\n4.  The view caches the result for a sensible interval so a busy counter does not call the service on every render.\n\nWhere the external system is Salesforce itself, the same relay approach applies: the page obtains the token, and the view uses it for the duration of its cache window rather than holding a long-lived credential.\n\nGive the relay page a purpose-specific path, treat it as a public endpoint, and return only the fields the register needs.\n\n## Consider the person at the counter\n\nExternal calls mean that a cashier might be waiting for information to advance an order or sale. Consider the following before setting up external data calls.\n\n-   **Latency.** Decide what happens while the answer is pending, and show it. A view that renders nothing while waiting reads as a broken screen.\n-   **Failure.** Decide what the operator sees when the service is down or slow, and make sure the sale can still proceed. An unavailable warehouse lookup should not block a cash sale.\n-   **Offline.** A register with no connection cannot reach an external service, and neither can it reach the relay page. Anything you show this way is absent during an outage, so it cannot be the only route to information the counter must have. See [Take payments while the POS is offline](offline-sales-at-pos).\n\n## Data display for decision-making\n\nShowing the answer is not the whole job. Once the data is visible, the cashier or operator may take an action, such as adding or changing a product, or adding information to a custom field on the cart, so it carries through to the order item. See the [POS actions reference](pos-actions-reference).\n\nConsider these details as part of the flow when choosing where data is needed. For example, if a cashier is able to choose a delivery date based on a carrier's real availability, this is ideal. Manually entered notes are less reliable in this scenario."}