How to Find a Brand's Store Locator API Endpoint

Almost every store locator on the web is a client-side widget talking to a JSON endpoint. Developers end up looking for that endpoint for all sorts of reasons: debugging their own locator, auditing what a vendor exposes, understanding why a competitor's locations are not indexed, or working out whether a platform can be integrated with. This is how they work, how to find one, and why you should not build anything durable on one you do not own.

Why the data is not in the HTML

View the source of most store locator pages and you will find an empty div and a script tag. The locations are not there. They arrive in a second request after the page loads, usually as JSON, and the widget renders them client-side.

That architecture is why the endpoint exists at all, and it is also the single most important fact about store locator SEO: if the store data only ever appears after a JavaScript request, there is no per-location URL and no indexable content for a search engine to rank. We cover that consequence in the store locator SEO guide.

Finding the endpoint in devtools

1. Open the locator page and open devtools, then select the Network tab.
2. Filter to Fetch/XHR. This removes images, fonts and stylesheets and usually leaves a handful of requests.
3. Run a search on the page — enter a postcode, or allow geolocation. Watch which request fires in response.
4. Look for a response with an array of objects containing address-shaped fields. Request URLs commonly contain stores, locations, locator, storelocator, branches, or dealers.
5. Check the Headers tab for the method, query parameters, and any authentication header — a lot of endpoints take latitude, longitude and a radius, and some require an API key the widget was issued.

If nothing appears, three common explanations: the store data was server-rendered into the initial HTML (look for a JSON blob inside a script tag), the data was bundled into the JavaScript at build time, or the request fired before you opened the Network tab — reload with devtools already open.

What the responses usually look like

Four shapes cover almost everything you will meet:

• A flat JSON array of locations. The most common by far. Each object carries a name, address components, latitude and longitude, and often hours, phone, and category tags.
• A wrapped response. The same array nested under a key such as results, data, or stores, usually alongside a count and pagination fields.
• A proximity query. Takes latitude, longitude and a radius, and returns only nearby locations already sorted by distance. This is the shape a well-designed locator API uses, because it does not require shipping the whole estate to the browser.
• Legacy formats. JSONP on older sites, XML on some enterprise platforms, and occasionally a rendered HTML fragment that the client injects directly.

Why building on somebody else's endpoint is a bad bet

Set the legal question aside for a moment; the engineering argument is enough on its own. An undocumented endpoint is an implementation detail, not an interface. It carries no compatibility promise, and every one of these happens routinely:

• The response shape changes at the next front-end release.
• It moves behind authentication, or starts requiring a token minted by the page.
• Rate limiting appears, and your integration starts failing intermittently in a way that is miserable to debug.
• The site changes locator vendor and the endpoint disappears entirely.
• The data itself goes stale in ways you cannot see, because nobody owes you a changelog.

If a locator integration matters to your business, it needs a documented API with a versioning story and someone accountable for it.

If it is your own locator, use a real API

The version of this problem worth solving is the internal one: your own systems need your own location data, and reverse-engineering your own widget is a sign the product is missing an interface.

Maptera includes a documented REST API on the Scale plan at $19/month — nearest-store and location endpoints over JSON, with API key authentication — so headless front ends, mobile apps, routing systems and internal tools query a stable interface. See the store locator API overview, the API install guide, and the API docs.

Not building anything? Then you probably want the widget rather than the API — how to add a store locator to any website covers every platform, and the free plan needs no card.

A note on auditing your own vendor

One legitimate and underrated use of this technique: checking what your current locator actually exposes. Open your own locator, watch the request, and ask whether the response contains more than the page displays — internal identifiers, unpublished locations, commercial fields, or staff contact details. Locator widgets frequently ship more data to the browser than anyone intended, and nobody notices because the UI never renders it.

While you are there, check whether the locator produces any crawlable per-location URLs at all. If the answer is no, the locator is not contributing to search regardless of how good the data is — run the store locator SEO audit to see what that costs you.