Store enumeration and footprint mapping
Use Whataburger endpoints to turn store enumeration and footprint mapping into repeatable API requests with documented inputs and JSON responses.
Turn Whataburger's own sitemap-declared store index into structured JSON — about 3,950 URLs from a single flat sitemap, each entry typed by kind, plus full per-store detail for any store path. Credential-free.
Enumerate Whataburger's ~3,950-URL store index and get full per-store detail as structured JSON.
Endpoint families
2
Documented params
6
Examples
2
Live catalog snapshot
Active endpoints
2
Methods
GET
Required params
3
Schema refs
2
{
"platform": "Whataburger",
"endpoint": "whataburger-sitemap",
"method": "GET",
"path": "/whataburger/sitemap",
"auth": "apiKey"
}Use cases
Enumerate Whataburger's ~3,950-URL store index and get full per-store detail as structured JSON.
Use Whataburger endpoints to turn store enumeration and footprint mapping into repeatable API requests with documented inputs and JSON responses.
Use Whataburger endpoints to turn local retail presence monitoring into repeatable API requests with documented inputs and JSON responses.
Use Whataburger endpoints to turn store-count benchmarking against competitor chains into repeatable API requests with documented inputs and JSON responses.
Managed execution
Every figure below is read from the live Whataburger endpoint catalog — 2 endpoints, 6 documented request parameters, and 2 published response schemas — the same catalog Docs and Playground run against.
2 documented Whataburger endpoints, grouped into 2 request families — Sitemap and Store.
6 request parameters are documented across those Whataburger endpoints, 3 of them required — the full input contract is public before you write any integration code.
2 of the 2 Whataburger endpoints ship a recorded example response, and 2 carry a documented response schema — you can code against the real JSON before the first request.
Whataburger endpoints document their error responses (400, 404, 429 and 503) alongside the success schema, so a block, a rate limit, or a missing record comes back as a typed error rather than silently empty data.
2 hosted MCP tools back the Whataburger endpoints, so an agent can call the same routes with the same parameters and the same JSON contract, with no custom glue.
Coverage map
These cards are generated from the active endpoint catalog, so the landing page reflects the same API surface used by Docs and Playground.
/whataburger/sitemap
/whataburger/store
Endpoint catalog
/whataburger/sitemapReturns one page of Whataburger's sitemap-declared store index -- about 3,950 URLs at time of writing. Unlike some other store locators in this API, Whataburger publishes a single flat sitemap file rather than a sharded index. Each entry carries a kind: "store" is a restaurant's canonical detail page, "curbside" and "delivery" are separate pages Whataburger publishes for that same restaurant's curbside or delivery service, and "directory" is a state- or city-level listing page with no address of its own. Filter with kind to enumerate one page variant. A page past the end returns an empty list rather than an error, so a caller can walk to exhaustion.
MCP tool whataburger_sitemap
/whataburger/storeReturns one Whataburger store: postal address, coordinates, phone, published week of opening hours, the restaurant services (curbside, delivery) Whataburger lists for it, and a per-channel hours breakdown (dine-in, drive-thru, curbside, delivery) where the channel's hours genuinely differ from the store's top-level hours. Store paths come from GET /whataburger/sitemap -- a store's canonical, curbside and delivery page paths all describe the same physical restaurant and return the same address; the response's own path field always reports the canonical page. Passing a state or city directory path returns a 404 rather than a hollow record. Note Whataburger's ordering/menu site returns no usable response for automated requests, so there is no credential-free menu source and this family is a locator only.
MCP tool whataburger_store
Related APIs
Marketplaces & Retail
Collect marketplace product signals from Amazon without building brittle storefront scrapers.
Marketplaces & Retail
Build resale, pricing, and marketplace workflows from structured eBay data.
Marketplaces & Retail
Turn public Shop.app product and merchant pages into structured JSON for e-commerce product intelligence, price research, shop monitoring, and marketplace discovery workflows.
How to scrape Whataburger
Crawlora's Whataburger endpoints return normalized public Whataburger store data as JSON with one API key — no Whataburger account required. Unlike Subway and Jimmy John's, Whataburger publishes a single flat sitemap rather than a sharded index.
Call /whataburger/sitemap to page through Whataburger's sitemap-declared store index — about 3,950 URLs at time of writing. Each entry carries a kind, and because Whataburger publishes one flat sitemap.xml rather than a sharded index, there is no shard parameter to walk.
Pass a store path from /whataburger/sitemap to /whataburger/store for that location's published detail.
Page through /whataburger/sitemap until the response comes back empty to know you've reached the end of the index, then resolve whichever store paths you need.
FAQ
Call /whataburger/sitemap to page through the store-URL index, then pass a store path to /whataburger/store for that location's full detail — both return structured JSON with one API key.
About 3,950 URLs at time of writing. Not every URL is a store page — each entry carries a kind, so filter on it to separate stores from other page types.
No — unlike Subway and Jimmy John's, Whataburger publishes a single flat sitemap.xml, so /whataburger/sitemap takes no shard parameter; just page through it.
Not in this first pass — this family covers the store index and per-store detail only.