Place Action Links: Google's restaurant ordering API, explained

By Trevor Anderson · May 13, 2026 · How-to · 7 min read

For years, the only way to build a multi-platform restaurant smart-link was to scrape. You scraped DoorDash for the store ID, Uber Eats for the restaurant URL, Grubhub for the merchant slug. The scraping broke every few months when the platforms changed their HTML. Every restaurant marketing tool that promised “automatic platform detection” was running a fleet of headless browsers and crossing their fingers.

In late 2023, Google opened up a Places API field that ended this. place_action_links returns the official, restaurant-claimed URLs for ordering on each major delivery platform, alongside reservation links and other actions. It is the same data Google uses to render those “Order online with DoorDash / Uber Eats / Grubhub” buttons inside the restaurant’s Google Business Profile.

If you are building anything that needs to programmatically resolve a restaurant’s ordering URLs, this is the right answer. Here is what it does, what it costs, and the gotchas you will hit.

What place_action_links actually returns

When you call the Places API v1 (places.googleapis.com/v1/places/{placeId}) with the right field mask, the response includes a placeActionLinks array. Each entry has:

placeActionType — one of PLACE_ACTION_TYPE_FOOD_ORDERING, PLACE_ACTION_TYPE_FOOD_RESERVATION, PLACE_ACTION_TYPE_FOOD_TAKEOUT, PLACE_ACTION_TYPE_FOOD_DELIVERY
providerName — the human-readable name of the provider (“DoorDash”, “Uber Eats”, “OpenTable”)
uri — the actual URL the diner is sent to when they click

For a typical urban restaurant, you will get 3-8 entries: DoorDash delivery, Uber Eats delivery, Grubhub delivery, ChowNow direct, OpenTable reservations, and sometimes a direct Toast or Square URL if the restaurant operates its own ordering.

The URLs are not scraped guesses. They are URLs the restaurant has explicitly claimed and verified through their Google Business Profile, or that the platform (DoorDash, Uber Eats) has registered with Google through an official integration. This means they are accurate, current, and survive the platforms changing their URL structures.

What it costs

The Places API v1 charges per “Place Details” request, with the cost varying by the field mask you include. The “Advanced” field tier — which includes placeActionLinks — is $17 per 1,000 requests as of writing.

For a smart-link platform like DineRoute, you call this once when a restaurant onboards, cache the URLs for 30-90 days, and refresh on a schedule or when a redirect failure is detected. A 200-location chain costs ~$3.40/year in Places API calls. For a single restaurant signup, the cost is essentially zero.

Compare that to scraping: a headless browser running 50 requests per minute on a $40/mo VPS, with monthly maintenance every time DoorDash changes their HTML, plus the legal and ToS exposure of scraping a public commerce site. The Places API is dramatically cheaper.

Gotcha 1: You need the Place ID, not the name

The API requires a Google Place ID. You cannot query by restaurant name and address directly — you have to resolve to a Place ID first. The “Find Place” or “Text Search” endpoints handle this:

Call places.googleapis.com/v1/places:searchText with the query “Malai Kitchen Southlake”
The response includes a places[0].id field — that is the Place ID
Call places.googleapis.com/v1/places/{placeId} with field mask placeActionLinks to get the order URLs

For onboarding, this is usually a two-step UI: the user types the restaurant name, you call Text Search, you show them the matches with addresses and let them pick the right one. Then you resolve to Place ID and pull placeActionLinks.

The “I have a restaurant name and address” → “give me ordering URLs” flow is two API calls, not one.

Gotcha 2: Not every restaurant has every platform

If a restaurant has never been listed on DoorDash, DoorDash will not appear in placeActionLinks. If a restaurant just signed up for Uber Eats two days ago, Uber Eats may not be there yet because the data hasn’t propagated.

The reverse is also true. A restaurant may genuinely be on Uber Eats but the Place Action Link is missing because the restaurant’s Google Business Profile never claimed the Uber Eats integration. In our experience, missing-from-API but actually-on-platform happens in 5-10% of cases.

The pragmatic move: use placeActionLinks as the source of truth for what to show by default, but allow restaurant operators to manually add a URL for any platform we don’t auto-detect. Show them a “Looks like we missed Caviar — add it manually” prompt.

Gotcha 3: Some links go to Google’s interstitial, not the platform

A subset of placeActionLinks URLs are not direct to the platform. They are Google-mediated URLs that pass through google.com/maps/... first and then redirect. These are clean for the user (one extra redirect, fast), but if you are firing a Meta CAPI event on the click, the event_source_url and the eventual destination differ.

This is a real issue for attribution chains because Meta may bucket the click differently if it sees a google.com referrer instead of doordash.com. The fix is to follow the redirect server-side once at onboarding, cache the final destination URL, and use that in your smart-link buttons. The user gets a faster click. The Pixel sees the right destination.

Gotcha 4: Postmates, Seamless, Caviar are aliased platforms

Google’s API will not return separate entries for Postmates (Uber Eats), Seamless (Grubhub), or Caviar (DoorDash). It returns the canonical brand. If the restaurant is technically listed on Postmates under the same Uber Eats store ID, the URL is the Uber Eats one. The marketing distinction (Postmates vs Uber Eats) is real on the consumer side, but on the API side they are the same listing.

If your smart-link wants to surface Postmates as a separate button, you either need to:

Construct the Postmates URL from the Uber Eats store ID (URL pattern is documented and stable)
Treat them as a unified “Uber Eats / Postmates” button and let the user pick

We default to the second approach because it is honest about the underlying architecture. Restaurants that specifically want Postmates branding (because their print collateral mentions it) can swap the button label.

Gotcha 5: The data refreshes asynchronously

When a restaurant claims their Google Business Profile or adds a new ordering platform, it can take 24-72 hours for the change to show up in placeActionLinks. If you are onboarding a brand-new restaurant, the API may return an incomplete list on day 1 and the full list on day 4.

The fix: schedule a refresh job that re-pulls placeActionLinks for every restaurant in your system every 30-90 days. Use the diff to flag changes (“Maple Branch added Grubhub, please review”). For onboarding flows, set the expectation that platform detection may improve over the first week.

What this means for restaurant marketing tools

Five years ago, building a multi-platform restaurant smart-link required scraping infrastructure, browser fingerprinting workarounds, and a maintenance schedule. The economics of doing it well were brutal. The economics of doing it poorly produced Linktree alternatives that broke every other month.

Now the API is available, the cost is trivial, the data is authoritative, and the implementation is a weekend project. The bar for “we resolve your platforms automatically” has gone from “we have a team of three keeping the scrapers alive” to “we make one API call and cache the result.”

What this changes:

Restaurant marketing tools should not be charging premium prices for “automatic platform detection.” It costs them $17 per 1,000 onboarding flows.
Restaurants signing up for tools should ask: do you use Place Action Links, or are you scraping? If they’re scraping in 2026, walk.
New entrants to the restaurant smart-link space (us included) can build a credible MVP in under two weeks. The historical moat is gone.

The remaining moat is everywhere downstream of the URL resolution: the Pixel + CAPI integration, the multi-location architecture, the agency tooling, the brand-aware page design, the analytics layer. Those still take real engineering. URL resolution is solved.

If you are evaluating a restaurant smart-link platform and they are vague about how they detect platforms, ask specifically. The answer should be “Google’s Places API, place_action_links field, refreshed every 30 days.” If it isn’t, you are paying for legacy infrastructure they should have retired.