What your POS integration does not tell you about your storefront
Restaurant operators reasonably assume that an integration connected to a delivery platform can see the storefront on that platform, and the published specifications say otherwise. These protocols were built to move orders and menus, and their scope is narrow enough to list. Everything a customer experiences that is not an order or a menu item sits outside them: which addresses are offered the branch, where it appears in a list, what its rating is doing, and several states the platform can apply that the integration has no field for.
Which endpoint groups does a delivery integration actually contain?
Fewer than most people expect, and the vendors publish the list. Talabat’s Partner API version 2.0.2 exposes its groups openly as Authentication, Catalog, Category, Order, Promotion and Outlet Management. Keeta’s published API covers Basic, Order, Store and Menu. Those two lists are close to the shape of the whole category: identity, the menu, the orders, a status flag for the outlet, and on some platforms a promotions writer.
Read that as a boundary rather than as a feature list. Anything a chain wants to know that does not fall inside one of those groups is not being withheld, it was never modelled. That is a more useful mental model than the common one, in which the integration is assumed to be a window onto the platform with some gaps in it.
Why is there no delivery area anywhere in the protocol?
Because on platform delivered orders the area is not the restaurant’s property. There is no delivery area object, no radius field, no zone identifier and no customer coordinates in Talabat’s Partner API, and the same holds for its point of sale integration documentation, which covers order management, catalogue management, store management and reporting.
The one place geography surfaces is a rejection reason, and the way it is scoped settles the question. Delivery Hero’s shared integration specification, which Talabat runs on, includes OUTSIDE_DELIVERY_AREA, described as “Vendor does not deliver to the customer’s address/area”, and marks it as available for VENDOR_DELIVERY orders only. Where the platform delivers, the protocol contains no way for the restaurant to have an opinion about an address, because the address was never its decision. A district that stops being offered your branch therefore produces no signal in the integration, no error, and no complaint, since the customer was never shown you.
Which platform states are unreachable from an integration by design?
Several, and they are the expensive ones. Keeta documents a platform override in which the platform suspends delivery while pickup continues, and states the consequence for the flag an integration reads: “The store’s overall status remains Open because pickup is still available.” A monitoring rule built on that status will report the branch as trading. Keeta also confirms the asymmetry, since “You cannot independently suspend or reactivate just one service line through the API.”
Jahez has removed store state from integrations altogether, and its certified integrator says so: “Deliverect can no longer open or close your store on Jahez. Any request to open or close your store must be made directly with Jahez, not through Deliverect.” Jahez additionally runs visibility as a second axis, with values “Visible”, “Hidden” and “Partially Visible”, and the documented remedy for a hidden store is to ask Jahez to change it. Deliveroo’s Forced Closure is a third case: it “can only be enacted by Deliveroo”, and an attempt to lift it returns the message “This closed period can only be updated by Deliveroo.”
Where does an integration report success on a request that partly failed?
In promotions, on at least two platforms, and both admit it. Talabat’s promotion jobs return per vendor validation results including invalid_vendors and invalid_discounted_skus, and for an update to an existing promotion the documentation states that “the job status will always be [successful] even if all items from the request are not valid”. HungerStation is equally explicit about its own limit: “Currently, there is no item-level error visibility when using Partner API/Promotions”.
So a chain pushing a discount to sixty branches can receive a clean result and have an unknown number of branches without the discount. This is the single most misleading class of blind spot, because it is not silence. It is a positive confirmation of something that did not fully happen, which is worse than no information at all and considerably harder to argue with internally.
Which channels can change the storefront without touching the integration?
Hardware, mostly. Deliveroo confirms that “a store can still be manually opened or closed using the Deliveroo tablet” independently of its Hub, and Talabat tells partners that “Using our tablet, you can pause your store from collecting orders for a specific time period.” Deliverect’s Jahez guidance describes the resulting collision, where an order fails because it “was already accepted on the Jahez tablet or dashboard instead of through Deliverect”, and advises turning the tablet channel off entirely.
Deliveroo also documents a reporting hole inside its own web tooling: “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.” A chain checking the web application for integration problems is therefore checking a surface that does not display them. None of this is exotic. It is a normal estate with a tablet on the counter.
What does a healthy order feed prove, and what does silence prove?
Less than either seems to. Careem states that “If you are POS integrated, the order will be automatically accepted”, which means acceptance is a property of the integration rather than evidence that a kitchen saw the order. A feed with no failures in it is compatible with a branch that is not preparing anything.
Silence is worse, because it is genuinely ambiguous. No orders can mean no demand, a listing that is dark, a listing that is present but not being offered to any address, or a menu that failed to publish. Every one of those produces the same reading in the integration, which is nothing. This is why an alert threshold set on order volume behaves badly: it fires on quiet nights and stays silent through a listing that vanished at eleven in the morning on a Tuesday.
What can the platform do to your listing that no integration will report?
Remove parts of it. noon Food reserves the right, “at its sole discretion”, to “remove from the Noon Food Platform any Item” it considers unsuitable, which produces an open branch with a missing dish and no event anywhere in the order feed. noon separately disclaims availability of its own tools, stating under the heading “No Service Guarantee” that they “may be unavailable at any time and for any reason”, which means the channel a chain would use to check is itself out of scope for any commitment.
The pattern across all of these is consistent. The integration is authoritative about what it carries and silent about everything else, and the things it is silent about are the ones a customer experiences directly. Reading the public storefront from the customer side is the only vantage point that covers them, which is what Kitchain (kitchain.co) does alongside, not instead of, an integration. The narrower question of how the two status signals differ is at storefront status and POS status are not the same thing.