Store locator and coverage research
Usa los endpoints de Starbucks para convertir store locator and coverage research en solicitudes API repetibles con inputs documentados y respuestas JSON.
Turn Starbucks — the world's largest coffeehouse chain — into structured JSON: store locations by coordinate, the full public menu, and per-product nutrition that recalculates for customizations like milk, size, and shots, all with one API key.
Find nearby Starbucks stores, browse the full menu, and get product detail with full nutrition — including customized drinks — as structured JSON.
Familias de endpoints
4
Parámetros documentados
21
Ejemplos
5
Snapshot en vivo del catálogo
Endpoints activos
5
Métodos
GET, POST
Parámetros obligatorios
12
Referencias de esquema
5
{
"platform": "Starbucks",
"endpoint": "starbucks-stores",
"method": "GET",
"path": "/starbucks/stores",
"auth": "apiKey"
}Casos de uso
Find nearby Starbucks stores, browse the full menu, and get product detail with full nutrition — including customized drinks — as structured JSON.
Usa los endpoints de Starbucks para convertir store locator and coverage research en solicitudes API repetibles con inputs documentados y respuestas JSON.
Usa los endpoints de Starbucks para convertir menu and pricing monitoring en solicitudes API repetibles con inputs documentados y respuestas JSON.
Usa los endpoints de Starbucks para convertir nutrition data for diet and health apps en solicitudes API repetibles con inputs documentados y respuestas JSON.
Ejecución gestionada
Cada cifra de abajo se lee directamente del catálogo de endpoints en vivo de Starbucks — 5 endpoints, 21 parámetros de solicitud documentados y 5 esquemas de respuesta publicados — el mismo catálogo contra el que corren Docs y Playground.
5 documented Starbucks endpoints, grouped into 4 request families — Product, Menu and Nearest Store, plus 1 more.
21 request parameters are documented across those Starbucks endpoints, 12 of them required — the full input contract is public before you write any integration code.
5 of the 5 Starbucks endpoints ship a recorded example response, and 5 carry a documented response schema — you can code against the real JSON before the first request.
Starbucks 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.
5 hosted MCP tools back the Starbucks endpoints, so an agent can call the same routes with the same parameters and the same JSON contract, with no custom glue.
Mapa de cobertura
/starbucks/product/{product_number}/{form}
/starbucks/menu
/starbucks/nearest-store
/starbucks/stores
Catálogo de endpoints
/starbucks/storesReturns Starbucks store locations near a point: store number, name, phone, full address, coordinates, weekly opening hours, amenities, and pick-up options. Either place, or both lat and lng, is required. place is free-text (city, address, or postal code) and is geocoded by Starbucks itself, so it works worldwide. market selects which Starbucks country site answers, one of us or ca, defaulting to us; this is not cosmetic even for stores, because the same store reports different operational data depending on the host. There is no filter parameter: Starbucks' own API accepts a features amenity filter but silently ignores it, so it is deliberately not offered here; filter on each store's returned amenities instead. A place Starbucks cannot resolve returns a well-formed empty result with place_not_found set to true rather than an error. The upstream returns at most 50 stores per request and supports no pagination; result_capped is true when that ceiling was reached. Store discovery works worldwide, but hours, amenities, and phone numbers are populated per market and may be absent outside the US and UK.
Notas de la respuesta
- Works worldwide. `place` is geocoded by Starbucks, so cities outside the US resolve normally — confirmed against Seattle, London, Tokyo, Paris, München, São Paulo, Dubai, and Sydney. Postal codes usually work (`98104`, `10001`, `SW1A 1AA`), but Starbucks' geocoder does not resolve every one of them (`90210` does not); a failure is reported as `place_not_found`, never as an error. - The upstream returns at most **50 stores per request and supports no pagination**. `result_capped` is `true` when that ceiling was reached, meaning more stores may exist nearby that cannot be retrieved. Query around different coordinates for wider coverage. - **Three distinct outcomes, none of them errors.** Stores found (`count > 0`); a `place` that could not be geocoded (`place_not_found: true`, `count: 0`); and a `place` that geocoded fine but has no Starbucks nearby (`place_not_found: false`, `count: 0`, e.g. Utqiagvik, Alaska). The same distinction applies to a remote `lat`/`lng`. - Each store lists its `amenities` with Starbucks' own codes: `16` (In Store), `AS` (MOP ASAP + Scheduled Ordering), `BE` (Blonde Espresso), `CC` (Scanless Order and Pay), `CS` (Café Seating), `DR` (Redeem Rewards), `DT` (Drive-Thru), `EM` (Starbucks Evenings), `GO` (Starbucks Wi-Fi), `NB` (Nitro Cold Brew), `OS` (Outdoor Seating), `WA` (Oven-warmed Food), `WF` (Wireless Hot-Spot), `XO` (Mobile Order and Pay). - **Field coverage varies by market.** Store number, name, address, and coordinates are returned everywhere, but `schedule`, `amenities`, and `phone` are populated per market. Measured across all 50 results per market: United States 50/50 have a weekly schedule, amenities and phone; United Kingdom 49/50; France 47/50 have a schedule but no amenities and no phone; Japan 0/50 have a schedule, amenities, or phone, and every store reports `hours_status` of "Store hours aren't available". Do not read an empty `schedule` as a closed store. - `store_number` is Starbucks' own public store identifier and is what `/starbucks/menu` and `/starbucks/product` accept as `store_number`. - `ownership_type_code` distinguishes company-operated (`CO`) stores from licensed ones such as airport and grocery kiosks. - `mobile_ordering_availability` is a live readiness state (e.g. `READY`, `NOT_READY`), not a static capability — a store that supports mobile ordering still reports `NOT_READY` while closed. Use the `XO` amenity code for the static capability. - `distance_miles` is the distance from the searched point.
Herramienta MCP starbucks_stores
/starbucks/nearest-storeReturns the coordinates and distance of the single closest Starbucks store to a point. Both lat and lng are required. This endpoint returns coordinates only, not store details: it is what Starbucks' own store locator uses to centre its map. Use /starbucks/stores for full store records. A point with no nearby store returns a well-formed result with found set to false rather than an error. market selects which Starbucks country site answers, one of us or ca, defaulting to us.
Notas de la respuesta
- This endpoint returns **coordinates only, not store details** — no store number, name, address, or hours. It is what Starbucks' own store locator uses to centre its map. Use `/starbucks/stores` for full store records, or feed `nearest_latitude` and `nearest_longitude` straight into it. - A point with no Starbucks anywhere near it returns a well-formed result with `found: false`, not an error — confirmed at Ushuaia, Argentina. - `distance_miles` is the distance from the searched point.
Herramienta MCP starbucks_nearest_store
/starbucks/menuReturns Starbucks' full menu as a category tree: top-level categories, their child categories, and every product with its product number, form, product type, sizes, default size, availability, and image. Pair a product's product_number and form with /starbucks/product to fetch full detail including nutrition. store_number optionally scopes the menu to one store, using a store number from /starbucks/stores; a store-scoped menu marks items that store does not carry with availability NotAvailableHere, while the unscoped menu reports everything as Available. market selects which country catalog to return, one of us or ca, defaulting to us; the two differ substantially (roughly 282 US products vs 253 CA, with exclusives on both sides). Only these two markets are available.
Notas de la respuesta
- Categories nest via `children`; products hang off the category that lists them. A category holds either child categories or products, not usually both. - Each product carries `product_number` and `form`. Pair those two with `/starbucks/product/{product_number}/{form}` to fetch full detail including nutrition. `product_detail_url` is the matching page on starbucks.com. - `form` is the lowercase form slug: `hot`, `iced`, `single`, `packaged`, `whole-bean`, or `via`. - `product_type` is Starbucks' own coarse classification in the menu tree: `Beverage`, `Food`, or `Coffee`. - `availability` is `Available` for every product on the unscoped menu. When `store_number` is given, items that store does not carry are marked `NotAvailableHere`, so a store-scoped menu is the only way to get real per-store availability. - This menu is Starbucks' **US catalog and is not localized** — there is no locale parameter, and the upstream ignores language negotiation. (The store locator, by contrast, genuinely is worldwide.) - No prices. Starbucks does not expose dollar pricing on this surface. - `category_count` counts top-level categories; `product_count` counts distinct products anywhere in the tree.
Herramienta MCP starbucks_menu
/starbucks/product/{product_number}/{form}Returns one Starbucks product's full detail: name, description, product type, image, Rewards star cost, customization options, and every size with its own nutrition panel (serving size, calories, calories from fat, and per-fact values for total fat with saturated and trans fat subfacts, cholesterol, sodium, total carbohydrates, protein, and caffeine). product_number is the numeric id from a /starbucks/menu result or a product page URL. form is that product's form; allowed values are hot, iced, single, packaged, whole-bean, and via. store_number optionally scopes availability to one store. Starbucks does not expose dollar pricing on this surface, so no price is returned; star_cost is the Rewards star cost. market selects which country catalog to resolve against, one of us or ca, defaulting to us. Each size also carries its default_recipe, the standard build, which is the required starting point for the /starbucks/product/{product_number}/{form}/nutrition endpoint. An unknown product number, or a form that product is not sold in, returns not found.
Notas de la respuesta
- Each size carries a `default_recipe`: the standard build for that size, as a list of modifiers with `sku`, `name`, `form_code`, and `option_product_number`. This is the required starting point for `POST /starbucks/product/{product_number}/{form}/nutrition`, which wants the complete modifier set rather than a change-set. `form_code` describes how a modifier behaves: `one` is a pick-exactly-one slot (the milk), `qty` is a countable (espresso shots, syrup pumps), and `modifier`/`yes-no` are toggles. - **No price.** Starbucks does not expose dollar pricing on this surface — it is store- and session-scoped behind its authenticated ordering flow. `star_cost` is the Starbucks Rewards star cost and is the only price-like value available. - Each entry in `sizes` carries its own `nutrition` panel: `serving_size`, `calories`, `calories_from_fat`, and a `facts` list. Facts cover Total Fat (with Saturated Fat and Trans Fat as `subfacts`), Cholesterol, Sodium, Total Carbohydrates, Protein, and **Caffeine**. - `daily_percent_value` is Starbucks' own preformatted percentage, e.g. `"15%"`. - Nutrition values are returned as strings. - `options` lists the customization categories Starbucks offers for the product, e.g. Milk, Flavors, Espresso. - `product_type` on this endpoint uses a different vocabulary from the menu tree's (`beverages` here versus `Beverage` there); treat it as an upstream label rather than a stable enum. - An unknown `product_number`, or a `form` that product is not sold in, returns a not-found error.
Herramienta MCP starbucks_product
/starbucks/product/{product_number}/{form}/nutritionRecalculates calories, fat, sugars, and protein for a customized build of a Starbucks beverage: swap the milk, change the number of espresso shots or syrup pumps, and get the real figures for that exact drink rather than the standard recipe. Starbucks only offers this for four hot espresso beverages; product_number and form must be one of 406/hot (Caffe Americano), 407/hot (Caffe Latte), 408/hot (Caffe Mocha), or 413/hot (Caramel Macchiato). Any other product returns an invalid-parameter error naming the four that work. size_sku comes from a /starbucks/product result's sizes[].sku. modifiers is the COMPLETE build, not a change-set: start from that size's default_recipe, adjust what you want, and send the whole list back; an empty list is rejected. Each modifier needs a sku, an optional quantity (defaults to 1, and is the dial that matters for countable modifiers like espresso shots), and an optional replaced_sku when substituting a pick-one slot such as the milk. This returns Starbucks' own four-value dynamic-nutrition panel, which is smaller than the full per-size panel /starbucks/product returns for the standard build.
Notas de la respuesta
- `values` is Starbucks' own four-value dynamic-nutrition panel (calories, fat, sugars, protein). It is deliberately smaller than the full per-size panel `/starbucks/product` returns for the standard build, so the two endpoints complement each other rather than overlap. - The figures genuinely recalculate. A Short Caffè Americano reports 0 calories with its default single espresso shot and 25 calories plus 2g protein with six. - `modifiers` is echoed back with defaults applied, so the response records exactly which build produced the figures. - No prices are returned. Starbucks does not expose dollar pricing on this surface. Example request: ```json { "size_sku": "93", "modifiers": [ {"sku": "55", "quantity": 6}, {"sku": "11010168", "quantity": 1} ] } ```
Herramienta MCP starbucks_nutrition
APIs relacionadas
Marketplaces & Retail
Research new, used, and vintage instruments across Reverb listings, seller shops, and the Price Guide. Keep current asking prices separate from historical sales, and preserve model, finish, year, condition, and currency when comparing gear.
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.
Cómo hacer scraping de Starbucks
Crawlora's Starbucks endpoints return normalized public Starbucks ordering data as JSON with one API key — no Starbucks account required.
Pass a latitude and longitude to /starbucks/nearest-store for the single closest Starbucks, or to /starbucks/stores for every nearby location with hours and address.
Call /starbucks/menu for Starbucks' full public menu, then pass a product number and form (such as size) from it to /starbucks/product/{product_number}/{form} for that item's detail and nutrition.
POST to /starbucks/product/{product_number}/{form}/nutrition with a customization — milk type, size, or shots — to get nutrition figures for that specific drink build instead of the default recipe.
Preguntas frecuentes
Call /starbucks/stores or /starbucks/nearest-store with a coordinate for locations, /starbucks/menu for the full public menu, or /starbucks/product/{product_number}/{form} for one product's detail and nutrition — all return structured JSON with one API key.
Yes — POST the customization (milk, size, shots) to /starbucks/product/{product_number}/{form}/nutrition to recalculate nutrition for that specific build, instead of only the default recipe /starbucks/product/{product_number}/{form} returns.
No. All five endpoints read Starbucks' own public ordering site and require only your Crawlora API key.
/starbucks/nearest-store returns a single closest location for a coordinate; /starbucks/stores returns every nearby store within range, each with its own hours and address.