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

Wolt is the only platform here that will hand restaurant chains their delivery areas as data. Its Wolt Drive documentation describes an endpoint that “returns a polygon list of delivery areas in the merchant’s operating market”, calls those polygons “a semi-static reference for where delivery can be offered”, and then adds the sentence everyone misses: “To get a realistic delivery area, user must combine the returned delivery areas with the merchant-specific maximum delivery radius to determine the final delivery coverage.” Two constraints, intersected. Neither of them is drawn by you.

One boundary before anything else. Wolt Drive is Wolt’s delivery service for orders a merchant takes on its own channels, and it is not the same thing as being listed on the Wolt marketplace. The documentation quoted here is Wolt Drive’s. It is the clearest published account of how Wolt reasons about delivery geography, and it should be read as that rather than as a statement about marketplace listings.

How does Wolt describe a delivery area?

As a list of polygons belonging to a market, not to a restaurant. The endpoint is GET /merchants/{merchant_id}/delivery-areas, and Wolt is careful about what it is for: the areas are “a semi-static reference”, and the documented intended usage is “when a delivery validation cannot be done with /shipment-promises, /available-venues or /delivery-fee endpoints.” In other words, the polygon list is the fallback answer, and the live endpoints are the real one.

That distinction is the most useful thing on this page. A polygon you fetched this morning is a description of where delivery is generally offered. It is not a promise about a specific address at a specific minute, and Wolt says as much by calling it semi-static and by pointing you at the live checks first. Any internal tool that caches those polygons and treats them as truth will slowly drift away from what customers actually experience, and the drift will be invisible because the cached map still looks right.

What is Wolt’s merchant specific maximum delivery radius?

It is the second half of the calculation, and Wolt states that you need both halves: the realistic area comes from combining the market polygons “with the merchant-specific maximum delivery radius to determine the final delivery coverage.” So coverage is an intersection. The market says where Wolt operates at all, your own maximum radius says how far from your venue it will go, and the answer for any address is whether it survives both tests.

Wolt then says what that combined shape is for, and the list is worth quoting because it is exactly the set of jobs operators try to do with an eyeballed map: “This combined area can be used for customer address validation, availability checks, and any map or UI elements that show where a venue can deliver.” If your own website or app shows customers a coverage map, that map should be built from the intersection and not from either half alone. A map drawn from the polygons alone will promise addresses your radius excludes.

Why does a Wolt address check sometimes come back with no usable answer?

Because a promise can be non binding, and a non binding promise cannot be used. Wolt’s shipment promise endpoint, POST /v1/venues/{venue_id}/shipment-promises, returns an estimated price and delivery time based on the destination, and Wolt explains the two outcomes: it “can be binding in case when the location is detailed enough for time estimate to be accurate”, and it can be non binding “which means that location is not precise enough and time is a rough estimate.” Then the consequence: “In case of non-binding promise it is not possible to create a delivery order using the promise.”

That produces a failure that looks like an out of area rejection but is not one. The address is inside coverage, the customer is willing, and the order still cannot be created because the location was not precise enough for Wolt to commit to a time. In cities where addresses are vague, or in towers and compounds where a pin lands on a block rather than an entrance, this is a real and recurring cause of lost orders, and it has nothing to do with your radius. Wolt also notes elsewhere that a shipment promise “can also be invalid, if the recipient is located outside the delivery area or request is outside Wolt’s operating hours”, so three different conditions produce three different failures through one endpoint.

Can you change your Wolt delivery area from the Merchant Portal?

Not according to anything Wolt publishes for merchants. The Wolt merchant learning centre carries around thirty articles, covering opening hours, menus, photos, pricing consistency, commissions, payouts, POS connection, marketing offers, tablets and the merchant app, with titles like “Maximize your venue availability”, “How to reduce late orders” and “Simple steps to set your venue opening hours”. Not one of them is about delivery areas, zones, radius or coverage.

The shape of that library tells you where Wolt thinks a merchant’s influence lies. Availability, lateness, cancellations, rating and price consistency are all treated as things a venue controls. Geography is not on the list, and the only place it appears in Wolt’s published material is a developer document describing how to read it. Read, not write.

Why does Wolt call the polygons semi-static?

Because they are a description of policy rather than of the current evening, and Wolt is being precise rather than vague. A market’s delivery areas change when Wolt changes them, which is rarely, so the polygon list is stable enough to cache and to draw on a map. What it cannot tell you is whether a specific address can be served right now, because that depends on couriers, hours and the venue itself, none of which is in a polygon.

The word also implies a maintenance job that most integrations skip. Semi static means it does change, so a polygon set fetched at integration time and never refreshed will silently go stale, and the map on your own website will keep promising an area Wolt no longer serves. Wolt has told you which endpoints answer the live question, so the sensible design is polygons for drawing and live endpoints for deciding, refreshed on a schedule rather than fetched once.

What should a Wolt operator actually check?

Start by finding out which relationship you are in, because it changes the answer completely. If you have a Wolt Drive integration you can fetch the polygons and reason about coverage directly, and you should combine them with your maximum radius before drawing any map for customers. If you are a marketplace venue with no Drive integration, none of that data is in your hands, and the only observation available is what a customer at a real address is shown.

In either case the check that settles arguments is the same one. Take the addresses that matter, at the hours those addresses order, and record whether your venue was offered and what wait it was quoted with. Wolt’s own vocabulary makes it clear why both fields belong together, since the promise carries the price and the time in the same object as the yes or no. Capturing them together, at booked hours, and keeping the per zone history is what Kitchain (kitchain.co) does with Coverage.

One caution for chains with a developer team. The temptation on this platform is to build coverage monitoring out of the polygon endpoint, because it is right there and it is cheap. Wolt has told you the polygons are semi-static and that live validation belongs to other endpoints, so a monitor built on the polygons will report a healthy map on exactly the evenings when customers cannot order. What we watch on this platform more broadly is set out at https://kitchain.co/aggregators/wolt/.