Why Talabat says your restaurant does not deliver to an address you cover

Talabat sets the delivery radius, not the restaurant, and restaurant operators cannot widen it from the Vendor Portal. Talabat’s own partner FAQ defines the radius in time rather than in distance: “Our delivery radius is set to within a 15 minute drive time from the location of the business or shop.” A drive time boundary moves with traffic, so the same address can sit inside the zone on a quiet afternoon and outside it at eight on a Friday evening. Nothing in the Talabat Partner API exposes that boundary to you.

No availability measurement will ever catch this, ours included. Our panel counts the hours Talabat listings were fully offline in the UAE (1.81 percent of stated trading hours in July 2026), and an address that falls outside a live delivery radius contributes nothing to that number. The listing is open. It is selling normally to everyone inside the boundary. Only the customers on the wrong side of it are missing, and they were never counted in the first place because they never appeared.

What is the actual delivery radius Talabat gives a restaurant?

Talabat answers this on its own partner site, under the question “What is the radius of the talabat delivery?”: “Our delivery radius is set to within a 15 minute drive time from the location of the business or shop. This is to ensure our partners are close to their customers while keeping the orders fresh.” Two things follow. The radius belongs to Talabat and is stated as platform policy, not as a partner setting. And it is measured in minutes of driving, which is not a fixed shape on a map.

Most operators picture a delivery area as a circle with a number of kilometres attached. A 15 minute drive time is not a circle. It is an isochrone, a blob whose edges follow the road network, so it reaches much further along a fast arterial road than across a residential grid with speed bumps and no through route. A branch beside a highway junction covers ground that a branch three hundred metres away does not.

Why does the Talabat 15 minute drive time zone move during the day?

Because drive time is not a constant. The distance a rider covers in 15 minutes on a quiet afternoon is not the distance covered at eight on a Thursday evening, and Dubai and Kuwait City both have congestion patterns severe enough to halve it. If the boundary is drawn in minutes and the minutes buy fewer metres, the boundary contracts. Talabat does not publish how often it recalculates this or whether the recalculation is live, and we have not found any Talabat page that states it, so treat the mechanism as documented and the refresh rate as unknown.

The practical consequence is that the edge of your delivery area is a variable, and it moves against you precisely when it matters. Peak dinner hours are peak traffic hours. An outer district that is comfortably inside the zone when you test it during a quiet weekday check can be outside it during the two hours that carry your week. That is the part operators find hardest to believe, because the check they run themselves almost always happens at the wrong time of day.

Can you change your Talabat delivery area from the Vendor Portal?

Talabat’s partner materials describe what the portal is for, and delivery geography is not on the list. Partners are told they get “the talabat Partner Portal and Partner App, where you can update your menu, track orders, analyze your performance and more”, and separately access to “talabat’s Vendor Portal, where you can find more details about the platform’s operations and logistics, training materials, and the ability to manage your listings.” Menus, orders, performance, listings. No delivery area control appears in any of it, so a district that stops ordering is a conversation with your account manager, not a support ticket.

Does the Talabat Partner API tell you which addresses can order from you?

No. The Talabat Partner API version 2.0.2 publishes its endpoint groups openly, and they are Authentication, Catalog, Category, Order, Promotion and Outlet Management. There is no geography anywhere in it. No delivery area object, no radius field, no zone identifier, no customer coordinates, no quoted delivery time. The same holds for the Talabat POS integration documentation, which covers Order Management, Catalog Management, Store Management and reporting and nothing spatial.

Outlet Management does exist, and Talabat describes it as the way to “Instantly update and retrieve your outlet’s status (open/closed) and schedule changes, reflecting current availability.” That is a binary for the whole outlet. A chain with a full POS integration can therefore read, at any moment, whether a branch is open, and cannot read whether a customer in Jumeirah Village Circle is being offered that branch. The integration was built to move menus and orders, and delivery geography was never in scope.

What does Talabat do when there are no riders in an area?

Talabat closes the whole outlet and says so. Talabat’s published closure reasons include TOO_BUSY_NO_DRIVERS and BAD_WEATHER, and both describe a vendor going off rather than an area shrinking. The documented vocabulary for a rider shortage on this platform is therefore a closure with a reason code, which is a different event from a boundary moving. We set out every code and who owns it in why a Talabat store shows as closed.

The difference is visible from the customer side and nowhere else. A rider shortage handled as a closure removes the branch from everybody, including the customer across the road, and the order flow stops dead within the hour. A rider shortage handled as a smaller radius removes the branch only from the far edge of the map, where volume was thin anyway, and nobody notices. Talabat documents the first mechanism. It publishes no delivery area object at all, so whether the second also happens cannot be established from its own sources.

Who owns the delivery area, you or Talabat?

The integration answers this in a way that is easy to miss. Delivery Hero’s shared integration specification, which Talabat runs on, publishes the full list of reasons a vendor may reject an order, and one of them is OUTSIDE_DELIVERY_AREA, described as “Vendor does not deliver to the customer’s address/area.” Every reason in that list carries an order type, and this one is marked VENDOR_DELIVERY only, meaning it exists solely for orders the restaurant delivers itself. NO_COURIER, described as “Vendor has no courier (drivers/couriers/walkers/etc) available to fulfill the order”, is scoped the same way.

Read the negative space there. When Talabat is doing the delivering, the restaurant is given no code for “I do not deliver to that address”, because the address was never the restaurant’s decision in the first place. The delivery area is a fact about Talabat’s operation that the restaurant inherits, and the platform has not left a slot in the protocol for the restaurant to disagree with it. That is a cleaner statement of ownership than anything on Talabat’s partner pages, and it is the reason this problem escalates commercially rather than technically.

How do you find out that a district stopped seeing your Talabat listing?

You cannot find it from inside your own systems, which is the structural problem. A customer who is outside the live radius is not shown an error and does not file a complaint. Your branch simply is not among the restaurants their app returns, so no order is attempted, nothing is logged in your POS, and the loss shows up months later as soft demand in one district. Talabat’s consumer FAQ describes the customer’s view of geography only in terms of cost, saying that “Delivery fees depend on multiple factors such as the restaurant/store and your location.”

The only place the live boundary is observable is the customer app itself, from a real address, at a real hour. Because Talabat draws its boundary in drive time, a coverage reading of a Talabat listing is only meaningful when it is taken at the hours that traffic is worst, which is exactly what Kitchain (kitchain.co) Coverage books its captures for at kitchain.co. For everything else about how this platform behaves, our full profile of it sits at https://kitchain.co/aggregators/talabat/.

Two checks make the conversation concrete rather than anecdotal. Take the same addresses at a quiet hour and at peak on the same day, and record which of them are offered your branch. Then repeat a week later. A district offered your branch at four and not at eight is a drive time effect. A district not offered it at any hour is a coverage change. Two different problems, two different answers, and the dated readings are what stop the discussion becoming an argument about impressions.