Storefront status and POS status are not the same thing
Storefront status is what a customer sees when they open your listing on a delivery app, while POS status is what your integration reports about its own connection, and the two answer the question “is this restaurant working” differently often enough to cost restaurant chains whole services. Talabat carries a closure code called TECHNICAL_PROBLEM. Snoonu pauses orders when it loses its connection and says so on screen. Keeta can leave a store reading Open while it suspends the delivery underneath it.
What is storefront status and what is POS status?
Storefront status is a property of the public listing. It is the state a customer meets: orderable, closed, busy, absent from search, present but unable to deliver to this address. It is produced by the platform, and the platform is the only party that decides it.
POS status is a property of the connection between a restaurant’s systems and the platform. It answers a narrower question, which is whether orders are flowing between two machines. Delivery Hero, whose middleware sits behind Talabat and HungerStation, models this as its own object, PosReachabilityStatus, with the values online and offline and an accompanying update carrying message, reason and status. That is a separate thing from the vendor’s availability, which lives in PosAvailabilityState with the values CLOSED_UNTIL, CLOSED, INACTIVE, UNKNOWN, OPEN and CLOSED_TODAY. Two objects, because they are two facts.
The confusion is understandable, because on a good day the two agree and one is a reasonable proxy for the other. The cases below are the days they do not.
Where do storefront status and POS status actually disagree?
Five documented cases, each of them ordinary rather than exotic.
The integration fails and the listing closes. Talabat and HungerStation both publish an eight value list of closure reasons that includes TECHNICAL_PROBLEM and UPDATES_IN_MENU, so a technical fault is a documented cause of a closed vendor rather than an exception to be argued about. From the kitchen’s point of view nothing happened at all.
The connection drops and the platform pauses orders on its own. Snoonu’s portal carries the string “No connection to Snoonu. Orders paused” alongside “Reconnecting services”. The pause is a consequence of the connection, not a decision by anyone.
The platform overrides the store from above. Keeta documents a state it calls Platform Override, in which it “may suspend delivery only while keeping pickup available”, and adds that “The store’s overall status remains Open because pickup is still available.” A monitor reading the top level status records a healthy store. A customer trying to order delivery cannot.
The listing is present, connected and invisible. Jahez runs two independent columns on its branches page, one for open and closed and one headed “حالة الظهور”, visibility, with the values “Visible”, “Hidden” and “Partially Visible”. Deliverect’s help centre describes the resulting symptom directly: “Even when everything is set up correctly, your store may not show up on the Jahez app. Ask Jahez to set your store’s visibility status back to ‘Visible.'” Uber Eats has the same idea as an enum value, INVISIBLE, documented as “Restaurant is not visible in app”.
The store is paused and the reason never reaches the merchant tool. Deliveroo states of its own web Hub that “POS errors don’t appear on the web app yet. If an order fails to transfer to the POS, it won’t show up in the Web app.”
Which delivery platforms model the two states separately?
The ones that publish an API, and the shape of the model tells you what the platform thinks can go wrong. Delivery Hero keeps reachability and availability in separate schemas, and adds a third flag that matters more than either: a changeable property that must be true before an availability change is accepted, with the guidance to check it “otherwise the request will be unsuccessful”. A store can therefore be connected, open, and forbidden from changing its own state.
Keeta splits the store into a headline status, where 3 is trading and 4 is an operational pause, and two sub statuses, deliveryRestStatus and pickupRestStatus, each of which can be available or unavailable independently. Its documentation notes that the store counts as Open “when either service is available”, which is precisely the arrangement that lets a listing look fine while half of it is off. Uber Eats separates authorship instead, returning an offlineReason of PAUSED_BY_UBER or PAUSED_BY_RESTAURANT alongside OUT_OF_MENU_HOURS and INVISIBLE.
DoorDash names the point of sale twice in its own list of deactivation reasons, with store_self_disabled_in_their_POS_portal and store_pos_connectivity_issues sitting beside payment_issue and operational_issues. Two of six causes are the integration, which is a fair summary of where the platform expects trouble.
Why does a healthy integration not guarantee an orderable listing?
Because several things that hide a listing happen entirely on the platform’s side of the connection, where no integration has visibility. A store closed by the platform, a visibility flag flipped, a delivery suspension applied during bad weather, a menu that failed validation, a listing that dropped out of a filtered view: none of those produces an error inside the restaurant’s stack, because nothing in the restaurant’s stack failed.
DoorDash provides the clearest example of the reverse trap as well. It publishes three conditions that make a reactivation attempt fail: “Store banking information is not present”, “Store banking information is invalid”, and “No active POS menus exists at the store”. A five minute connectivity fault becomes a multi day outage when the recovery is blocked by a lapsed banking record, and nothing on the shop floor will ever mention banking.
What can each vantage point do that the other cannot?
Inside the stack has one advantage that outside in monitoring does not have and cannot acquire: it can act. Tools built on the order integration read state through the same connection that manages orders, which means they can reopen a store, and for a chain running a single integrated stack that is genuinely valuable. Deliverect describes automatic store reopening as a feature of Sentinel for locations running its Restaurants integration, on its own product page. A monitor that only watches cannot do that.
Outside in has a different advantage, which is that it sees what the customer sees, including the states the integration is structurally unable to report, and it does not depend on the integration being present or healthy. It also produces a record that was not generated by the systems under discussion, which is what makes it usable as evidence with a platform. Kitchain (kitchain.co) reads the public storefront and reports, and does not reopen stores or change anything in restaurant systems.
Neither vantage point is a substitute for the other, and a chain running an integrated estate has an argument for both: recovery inside the stack, verification outside it, including on the platforms the integration does not reach. Our comparison of that product category is at Deliverect Pulse Sentinel alternatives.
Which status belongs in the record you take to the platform?
The storefront one, because it is the only version of events that describes what the customer met. An integration log is a record of your own system’s opinion of itself, and where the disagreement is the whole subject of the conversation, a log produced by one of the two parties is a weak instrument.
The practical form of that record is a series of timestamped observations of the public listing, checked against the hours the location told the platform it would trade, which is set out at our methodology. Once you have it, the next question is who caused the state, and the tells for that are at paused by the branch or closed by the platform. If the argument is instead about what the integration could have been expected to see, the endpoint by endpoint scope of these protocols is set out on what your POS integration does not tell you about your storefront.