JD Shop Keyword Search
Give one JD shop ID, an in-shop keyword, and an expected count to collect matching products with titles, prices, and shop context.
Overview
In-shop keyword search on JD shows how one merchant presents products for a buying intent. Official items, accessories, and related SKUs sit together on that shop's search page, so the same query can look very different from site-wide results. Seeing those cards in one table makes it easier to judge which titles, price points, and SKUs the shop actually surfaces, without opening listings one by one.
This collection keeps original product titles, displayed JD and original prices, images, and shop context from public in-shop search results. It is useful when a merchant's keyword assortment and list-page pricing are the input to sourcing or competitive review, rather than replacing a product-detail check or a purchase decision.
Data notes
The data describes product cards collected from public JD in-shop keyword search for one shop and one keyword. Results are delivered in ascending collection-time order, which is separate from the sorting used to select products during collection. Repeated SKU IDs are consolidated across the delivered pages.
Product title, JD price, Original price, Review count and Sales count retain their source text. Prices are not converted into another currency, and no assumptions are made about taxes, promotions, or purchasing conditions. Business ID and Keyword can carry the same search phrase; neither is a unique product identifier. Submitted item keeps the shop and keyword context and may repeat across many products from the same task. The time zone of Collection time is not specified. Product image addresses may start with // rather than a full http prefix.
Missing brand, price, sales-count, and listing-status values remain missing rather than being inferred. A blank preview does not assert that the corresponding source value is an empty string. No-data indicator distinguishes a submitted shop-and-keyword item that produced no matching products from ordinary listing rows. The collection should not be treated as a complete shop catalog, a stock snapshot, or a verified offer for a particular order.
What the results look like
Each row represents one in-shop JD search-result listing for the submitted shop and keyword.
| SKU ID | Product title | Shop name | Keyword | Collection time |
|---|---|---|---|---|
| 10106482729387 | ZEEHO极核插画车型主题高透亚克力钥匙扣 ae8 | ZEEHO官方旗舰店 | 钥匙扣 | 2026-10-14T17:02:03 |
| 100007662145 | ZEEHO极核钥匙扣挂件 | ZEEHO官方旗舰店 | 钥匙扣 | 2026-10-14T17:02:03 |
Additional columns include JD price, Original price, Image URL, and No-data indicator.
Use cases
- Compare in-shop assortment: group Product title by recurring product or accessory terms, then use SKU ID and Shop name to separate distinct listings behind the same Keyword.
- Review displayed pricing: compare JD price and Original price for listings with similar Product title wording, keeping the original text before drawing conclusions about competitiveness.
- Prepare a shortlist: combine Keyword, Product title, Image URL, and Shop name to identify relevant candidates, and retain Collection time so later reviews can distinguish collection snapshots.
Scope and boundaries
One JD shop ID and one in-shop keyword per task, with an expected product count from 1 to 12,000. The count is a collection target, not a hard result cap, so fewer or more listings may be returned. Fetch protection is 12 pages / 12,000 records; reaching this capacity does not establish completeness. Coverage is limited to public JD in-shop search listings.
- Good for
- When you need products that match a keyword inside one JD shop rather than site-wide search results.
- When you want a structured list that connects each matched listing with its title, displayed prices, and shop context.
- Do not use for
- When you need a full product page, variants, reviews, or the complete shop catalog without a keyword filter.
- When you need a strictly capped result count or an immediate single-record lookup.
Failure handling
Failure and retry behavior declared by the developer. We recommend including it in your system prompt when integrating.
- 1If submission times out or its outcome is unknown, check the existing run before submitting again: repeated submissions can create separate jobs.
- 2If no matching records are returned, check the shop ID and try a shorter or broader in-shop keyword, then resubmit.
- 3Keep completed records after a partial success; resubmit the same input after a failed or expired task.
- 4Retry later after rate limiting, temporary service unavailability, or a timeout.
- 5If authentication fails, verify the API Key configured for the execution environment.
Input
Parameters required to call this App, generated from the input.schema in manifest.json.
- JD shop ID
shop_idRequiredstringEnter the ID of the JD shop whose in-shop search results you want to collect. Use one shop ID per task, from 1 to 512 characters.Example11635291 - In-shop keyword
keywordRequiredstringEnter one keyword to search inside the shop, from 1 to 512 characters.Example钥匙扣 - Expected product count
target_countRequiredintegerEnter a whole number from 1 to 12,000. This is a collection target, not a hard result cap; the actual count follows what is collected and may be lower or higher.Range1–12000Example10 - Collection sort order
sort_orderRequiredstring(enum)Choose how products are selected during collection: Default, Sales, Review count, Newest, Price: low to high, or Price: high to low. Delivered rows remain in ascending collection-time order.Allowed valuesDefault0Sales2Review count3Newest4Price: low to high51Price: high to low52Example0
Output
Field structure of a single record, generated from the output.schema in manifest.json.
- SKU ID
skuIdstringJD product identifier used to distinguish listings.Example10106482729387 - Business ID
bizIdstringSearch keyword retained on the listing; not a unique product identifier.Example钥匙扣 - Product title
productTitlestringProduct title as collected, without translation.ExampleZEEHO极核插画车型主题高透亚克力钥匙扣 ae8 - JD price
jdPricestringJD listing price as collected text; missing values are not filled in. No separate currency field is provided.
Sample data
Generated from output.schema. Fields without a sample value use structural placeholders.
{
"skuId": "10106482729387",
"bizId": "钥匙扣",
"productTitle": "ZEEHO极核插画车型主题高透亚克力钥匙扣 ae8",
"jdPrice": "<jdPrice>",
"originalPrice": "<originalPrice>",
"saleCount": "<saleCount>",
"rateCount": "<rateCount>",
"brandName": "<brandName>",
"imageUrl": "//img12.360buyimg.com/n7/jfs/t1/224484/24/20441/30093/666a9032Fee15908b/1ef4fa11ad6ec0fc.jpg",
"shopId": "11635291",
"shopName": "ZEEHO官方旗舰店",
"keyword": "钥匙扣",
"status": "<status>",
"crawlTime": "2026-10-14T17:02:03",
"taskItem": "{\"keywords\":\"钥匙扣\",\"shop_id\":\"11635291\"}",
"taskNoData": false
}Integration
This App can be integrated via MCP, API, SDK, or file export. All channels share the same capabilities and pricing. Every request authenticates with the Authorization: Bearer header using an API key (long-lived, created in the Data Hub Console); MCP clients can also sign in with OAuth, no key required. More options such as CLI and Skill are on the way. This App runs asynchronously and can be canceled midway: After you cancel, the run stops. Records already delivered are kept and billed.
With the MCP (Model Context Protocol), you can call this App directly from AI clients like Claude and Cursor. Pick your client and auth mode, then copy the config below.
Client config
Replace the value after Bearer with your long-lived API key. Works in any client, CI, or headless environment.
{
"mcpServers": {
"octoparse_datahub": {
"type": "http",
"url": "https://mcp-v2.octoparse.com?pin=super_ig/jd-shop-keyword-search",
"headers": { "Authorization": "Bearer <YOUR_API_KEY>" }
}
}
}Let AI set it up for you
Don't want to edit configs by hand? Copy the install prompt and paste it into any AI client. It will complete the setup its own way. (The prompt asks the AI to request your API key from you, so credentials never end up in chat history or shared configs.)
detail.access.mcp.composeHint
Pricing
Charged once per submitted run, regardless of how many records are returned.
Charged by the number of records successfully returned. Failed runs are not charged. Billed in units of 60 records; any partial unit is rounded up to 60 records.
Multiple billing events accumulate independently. See each item for details. Failed runs are not charged.
View creditsTry it now
Fill in the parameters and run. Results come from a real call.