Food-delivery menu and price monitoring
Swiggyエンドポイントを使えば、「Food-delivery menu and price monitoring」をドキュメント化された入力とJSONレスポンスによる再現可能なAPIリクエストに変えられます。
Turn Swiggy's public food-delivery data into structured JSON — restaurant and dish search around a latitude/longitude with veg, rating, offer and sort filters and a separate dish tab, the curated dish and cuisine collections Swiggy's own homepage surfaces for a location, one restaurant's detail, and its full menu grouped into categories with prices. Credential-free, including the AWS WAF challenge cleared server-side.
Search Swiggy restaurants and dishes by coordinate, browse curated collections, and get restaurant detail with full priced menus as JSON.
エンドポイントファミリー
3
ドキュメント化されたパラメータ
22
サンプル数
4
ライブカタログスナップショット
稼働エンドポイント
4
メソッド
GET
必須パラメータ
14
スキーマ参照
4
{
"platform": "Swiggy",
"endpoint": "swiggy-search",
"method": "GET",
"path": "/swiggy/search",
"auth": "apiKey"
}ユースケース
Search Swiggy restaurants and dishes by coordinate, browse curated collections, and get restaurant detail with full priced menus as JSON.
Swiggyエンドポイントを使えば、「Food-delivery menu and price monitoring」をドキュメント化された入力とJSONレスポンスによる再現可能なAPIリクエストに変えられます。
Swiggyエンドポイントを使えば、「Restaurant coverage and offer research」をドキュメント化された入力とJSONレスポンスによる再現可能なAPIリクエストに変えられます。
Swiggyエンドポイントを使えば、「India q-commerce market analysis」をドキュメント化された入力とJSONレスポンスによる再現可能なAPIリクエストに変えられます。
マネージド実行
以下の数値はすべて、稼働中のSwiggyエンドポイントカタログから取得しています（エンドポイント4件、ドキュメント化されたリクエストパラメータ22個、公開レスポンススキーマ4件）。DocsとPlaygroundが参照しているカタログと同じものです。
Swiggyのエンドポイントは4件、3つのリクエストファミリーに分類されています（Restaurant、Collections、Search）。
これらのSwiggyエンドポイントには22個のリクエストパラメータがドキュメント化されており、うち14個が必須です。統合コードを書く前に入力仕様をすべて確認できます。
4件のSwiggyエンドポイントのうち4件が実際のサンプルレスポンスを、4件がドキュメント化されたレスポンススキーマを備えています。最初のリクエストの前に実データの形に合わせて実装できます。
Swiggyのエンドポイントは成功時のスキーマに加えてエラーレスポンス（400、503）もドキュメント化しています。ブロック、レート制限、レコード欠損は空データではなく型付きのエラーとして返ります。
Swiggyのエンドポイントは4個のホスト型MCPツールとして提供されており、エージェントは同じパラメータと同じJSON契約のまま、追加の実装なしに同じルートを呼び出せます。
カバレッジマップ
これらのカードは稼働中のエンドポイントカタログから生成されるため、このページはDocsとPlaygroundが使うAPIサーフェスをそのまま反映します。
/swiggy/restaurant
/swiggy/collections
/swiggy/search
エンドポイントカタログ
/swiggy/searchReturns restaurants delivering to a latitude/longitude, optionally filtered by a keyword or browsed within a curated collection. With no query and no collection_id this browses the nearby-restaurant listing; with a query it runs a keyword search across restaurant names, cuisines, and dishes; with a collection_id (from /swiggy/collections) it browses restaurants within that curated collection. query and collection_id are mutually exclusive. Keyword search has two result tabs, selected with tab: dish (the default) returns restaurants that serve a matching dish, each with the matching dishes, their prices, and Swiggy's own per-dish rating where it has one, in a dishes array; restaurant returns restaurants whose own name or cuisine matches, a wider set with no dishes. tab, veg, min_rating and offers are only valid together with query. sort works with either query (relevance, delivery_time, rating) or collection_id (those three plus cost_low_to_high and cost_high_to_low), and is rejected on a plain nearby browse. Each restaurant carries its id (the value the restaurant and menu endpoints take), name, cuisines, cost for two, rating, delivery time, open/closed status, a hero image, and, where one is shown, an external_rating block with the third-party aggregate score, count, and source. Where the result card advertises a promotion it also carries offers, the same title/description/tag shape /swiggy/restaurant returns (a listing card never carries a coupon code, and a card showing both a discount and a separate free-delivery benefit returns them as two entries). is_promoted is present and true only for a result Swiggy itself labels a sponsored placement rather than an organic one. unavailable_message is present only when Swiggy says the restaurant cannot currently be ordered from and carries its own reason; it is not the inverse of is_open, since Swiggy reports a restaurant as open while still refusing orders for the requested location. A plain nearby browse also returns is_serviceable, which says whether Swiggy delivers to the requested coordinates at all: false means the coordinates are outside Swiggy's delivery coverage, so the empty restaurants list is a coverage answer rather than a no-matches answer, while an empty list without the field means no matches in a served area. It is omitted on keyword search and on a collection_id browse, neither of which carries Swiggy's own coverage marker.
MCPツール swiggy_search
/swiggy/restaurantReturns one Swiggy restaurant's detail by id: name, city, area, address, postal code, coordinates, phone, cuisines, cost for two, rating and total rating count, delivery time, weekly opening hours with the current open/closed callout, plus the promotions Swiggy currently shows on that restaurant's page (headline discount, conditions, and coupon code when one is needed). Swiggy has no lighter restaurant-detail-only source -- this reads the same upstream as /swiggy/restaurant/menu, just without the menu items.
MCPツール swiggy_restaurant
/swiggy/restaurant/menuReturns one restaurant's full menu grouped into categories, plus its restaurant summary. Every item carries a name, description, category, price, discounted_price when currently discounted, veg/non-veg flag, stock status, an image, and Swiggy's own per-dish rating and review count where it carries one. A category nested under a parent group on the live site (e.g. "Whopper" under "Burgers, Wraps & Tacos") is flattened to one level: its title is the parent's, with subcategory set to its own name. The response also carries the restaurant's current promotions in offers, the same block /swiggy/restaurant returns.
MCPツール swiggy_restaurant_menu
/swiggy/collectionsReturns the curated dish/cuisine collections Swiggy's own homepage surfaces for a latitude/longitude (e.g. "Idli", "Biryani", "Dosa"). Each collection's id is the value /swiggy/search's collection_id param takes to browse restaurants within it. The response also carries is_serviceable, which says whether Swiggy delivers to the requested coordinates at all: false means the coordinates are outside Swiggy's delivery coverage, so the empty collections list is a coverage answer rather than a location that simply has no curated collections.
MCPツール swiggy_collections
関連API
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.
Swiggyのスクレイピング方法
Crawlora's Swiggy endpoints return normalized public Swiggy data as JSON with one API key — no Swiggy account required. Swiggy's restaurant and menu surfaces sit behind an AWS WAF JavaScript challenge; that is cleared server-side through a browser render fleet, so the call itself needs nothing from you.
The search endpoint takes a latitude and longitude and returns the restaurants delivering there. Add a query of at least two characters to search restaurants and dishes — a single character is rejected — and pick which result tab to read: dish returns matching menu items, restaurant returns matching venues. Filters for veg-only, a minimum rating, and offer-running restaurants apply to keyword search, and the plain location browse pages through an opaque cursor instead.
The collections endpoint returns the dish and cuisine collections Swiggy's own homepage surfaces for a coordinate — Idli, Biryani, Dosa and the rest. Each collection's id feeds back into search as a collection_id, which browses the restaurants inside that collection rather than running a keyword query.
Pass a restaurant id from any listing to the restaurant endpoint for its address, coordinates, and the fields listing cards do not carry. It reads the same protected upstream as the menu endpoint, just without the items — Swiggy publishes no lighter detail-only source, so there is no cheaper path to a restaurant's address.
The restaurant-menu endpoint returns one restaurant's full menu grouped into its own categories, alongside the restaurant summary. This is where per-item pricing lives — listing cards carry the commercial framing (offers, promotion labels, unavailability reasons) but not the menu itself.
FAQ
Search restaurants and dishes around a latitude/longitude, or browse one of Swiggy's curated collections, then pass a restaurant id to the restaurant and restaurant-menu endpoints for its detail and full priced menu — all return structured JSON with one API key.
Not on your side. Swiggy's restaurant and menu surfaces sit behind an AWS WAF JavaScript challenge, which is cleared server-side through a browser render fleet. The request you make carries your Crawlora API key and nothing else — no Swiggy cookie, session, or account.
From the restaurant endpoint, not from a listing. Swiggy's search and browse cards deliberately omit address, coordinates, phone, and hours, so those come from the restaurant detail call — which reads the same protected upstream as the menu, since Swiggy publishes no lighter detail-only source.
The veg, minimum-rating and offers filters are keyword-search filters, and sort is valid with a keyword or a collection id but rejected on a plain nearby browse — Swiggy's own site exposes no sort control there either. The tab parameter, which chooses between dish and restaurant results, is likewise only valid alongside a query.
Yes — a result Swiggy itself labels as a promoted, paid-placement listing carries is_promoted true, and organic results simply omit the field. Results Swiggy says cannot currently be ordered from carry an unavailable_message with its own reason text rather than being dropped from the list.