Target

Target.com product detail, customer reviews, category browsing, and store locations behind the same unified envelope and canonical commerce schema as Amazon, Walmart, and Google Shopping, so one parser handles all four.

Base URL: /v1/target/...

Getting started

Every endpoint is a GET with query parameters and an x-api-key header. Start from a TCIN, Target's catalogue id, which is the number at the end of any Target product URL:

https://www.target.com/p/beats-solo-buds-true-wireless-bluetooth-earbuds/-/A-92148487
                                                                            ^^^^^^^^

curl "https://www.socialcrawl.dev/v1/target/product?tcin=92148487" \
  -H "x-api-key: $SOCIALCRAWL_API_KEY"

Endpoints

5 endpoints available.

Read this before you build

There is no Target keyword search, and that is deliberate. Target's search surface returns at most 24 products, ignores the page parameter entirely, and answers a query that matches nothing with 24 unrelated products rather than an empty list. There is no way to tell a real result from a miss, so shipping it would mean billing you for rows you did not ask for.

Browse instead. GET /v1/target/categories gives you the whole category tree for 1 credit, and GET /v1/target/category walks any node 24 products at a time with real prices and working pagination. That is the reliable path from nothing to a set of TCINs. If you specifically need keyword matching, use /v1/search/everywhere for a cross-source sweep.

A variant TCIN resolves to its parent product. Target rolls colours and sizes up: asking for 92146817 (Matte Black) returns the parent product 92148487, whose payload describes the family. product.id always carries the id of the product the payload actually describes, and product.ext.requested_id carries the id you asked for whenever the two differ, so the round trip is never lost. Colour and size options come back in product.variations, each with its own TCIN.

Target product pricing is national. Unlike Walmart, Target's product endpoint reports the same price whatever store is asked for, so there is no store or ZIP parameter here. Treat price.current as catalogue pricing rather than shelf pricing.

Typical flow

# 1. Get the category tree (1 credit, cached hard)
curl "https://www.socialcrawl.dev/v1/target/categories" \
  -H "x-api-key: $SOCIALCRAWL_API_KEY"

# 2. Walk a category for TCINs and real prices, 24 per page
curl "https://www.socialcrawl.dev/v1/target/category?category_id=hz89j" \
  -H "x-api-key: $SOCIALCRAWL_API_KEY"

# 3. Full detail on one product, including the 1-5 star breakdown
curl "https://www.socialcrawl.dev/v1/target/product?tcin=92148487" \
  -H "x-api-key: $SOCIALCRAWL_API_KEY"

# 4. Walk its reviews, 10 per page, passing the cursor back until has_more is false
curl "https://www.socialcrawl.dev/v1/target/reviews?tcin=92146817" \
  -H "x-api-key: $SOCIALCRAWL_API_KEY"

Already hold a TCIN? Skip straight to step 3.

De-duplicate a category crawl by product.id. Target's category ordering shifts between calls, so consecutive pages occasionally repeat a handful of products. We measured 0 repeats one morning and 4 of 24 the same afternoon on the identical category. Every row carries a stable id, so a Set is all it takes. Reviews do not have this problem: those pages are cleanly separated.

Stores

GET /v1/target/stores?query=10001 returns the Target stores near a ZIP code, city, or state, each with its store id, composed address, phone, distance, open status, timezone, and two weeks of daily opening hours. It is 1 credit because store data barely changes and caches hard.

Target publishes no coordinates for a store, so latitude and longitude are null rather than guessed; geocode the returned address if you need them. The store-locator extras ride on place.ext:

"ext": {
  "distance": 0.37,
  "status": "Open",
  "timezone": "America/New_York",
  "hours": [
    { "date": "2026-07-27", "day_name": "Monday", "is_open": true,
      "opens_at": "08:00:00", "closes_at": "23:00:00" }
  ]
}

A store id from here does not localise prices: see the pricing note above.

Reviews pagination

Target review pages do not overlap and the review total is exact, so a full crawl is deterministic: pass the returned pagination.next_cursor back as cursor until has_more is false. Page size is fixed at 10 and cannot be raised.

If what you actually want is the rating breakdown rather than the review text, call /v1/target/product instead and read product.ext.rating_distribution. It carries the same 1 to 5 star counts in a single call, rather than one call per ten reviews.

"ext": {
  "rating_distribution": {
    "star_1": 549, "star_2": 149, "star_3": 124, "star_4": 148, "star_5": 932
  }
}

Ratings and reviews are two different numbers

product.rating.count is the number of people who left a star rating. reviews_count is the number who wrote review text, and it is the same population /v1/target/reviews paginates over. On a typical product the first number is two to three times the second. Both are reported exactly as Target reports them; neither is an estimate.

Response shape

Products and reviews use the shared canonical commerce objects documented under Schema. A Target product and a Walmart product have the same leaf names, so a price-comparison integration needs one mapping, not one per retailer.

Notes

• All endpoints use GET with query parameters
• Authentication via the x-api-key header
• Responses follow the unified SocialCrawl schema
• Empty results and not-found TCINs are refunded automatically and never billed
• Prices are US dollars; Target is a US-only retailer and there is no marketplace selector