Vietnam's marketplace as JSON, priced in dong and pinned to the right seller

For full coverage, yes, and the API tells you when you have not. Tiki matches the words printed in a product title and does not translate, so an English term returns a small, off-topic set with no error at all: điện thoại returns over 10,000 results and phone returns 92; tã bỉm returns 7,635 and diaper returns 2, one of which is a book. Diacritics are passed through exactly as you send them and are never stripped, because the accent-free spelling is a different query rather than the same one - giày returns 4,608 results and giay returns 8,802, and the two share only 1 row in 40. Any query with no Vietnamese diacritics comes back with a query_note saying this.

Because one Tiki product id can carry several merchants' offers, and the two ids together name one offer. Give the API both and you get that merchant's price. Give it only the product id and Tiki answers with whichever offer its buybox picks - measured on 30 products, 2 came back with a different merchant at a different price, the worst 104,250 dong against 73,000 for the same book. Every product row and every product URL this API returns carries the right seller_product_id, and if you paste a tiki.vn URL that has one, it is used automatically. When it is missing, the record returns offer_is_buybox true so you always know which case you are in. The other_sellers block on the product record lists every rival offer with its own price.

Forty products a page, up to page 50, so 2,000 rows per query however large the match count is. total_results is the exact number when Tiki publishes one and null when it publishes the ceiling text 10000+ instead - the API never invents an integer out of that, and total_results_text always carries Tiki's own words while total_results_capped tells you which of the two you are holding. Reviews page far deeper: 7,046 reviews over 353 pages on one product, twenty a page.

Yes, and the API does the part Tiki leaves out. Sorting by price genuinely selects a price band that moves as you page - on the query sách, page 1 spans 9,500 to 14,000 dong, page 2 spans 14,000 to 25,000 and page 10 spans 40,000 to 41,000 - but Tiki hands the forty rows back newest-listing-first inside that band rather than in price order. This API re-orders the page by price and sets page_reordered so you know it did, and price_band_vnd reports the page's real span so the occasional just-listed product that lands outside the band stays visible instead of being hidden. Unknown sort values are rejected rather than silently ignored.

There is a real availability signal and no real stock number, and the API does not pretend otherwise. in_stock and inventory_status come from Tiki's own status for the offer. Tiki also publishes a quantity field on every product, but it was the identical value 1,000 on all 19 products checked across 7 categories - it is a per-order cap, not inventory - so it is returned as max_order_qty and min_order_qty, under the meaning it actually has, and never as stock. Variants carry their own availability status but no per-variant count, because Tiki does not publish one.

Four, all counted rather than assumed, across six categories of forty rows each. Books carry no brand at all - brand_id and brand_name were absent on 40 of 40 book rows and present on 40 of 40 rows in every other category - so the brand action cannot cover the book catalogue. rating is null on most rows because most Tiki products have no reviews yet: 6 of 40 book rows and 9 of 40 shoe rows carry one, and review_count is still returned as 0 because zero reviews is a real answer. quantity_sold is absent when Tiki does not publish it, on 124 of 280 rows. origin is filled on 34 to 40 of 40 rows in most categories but only 7 of 40 on books. Everything else - id, name, both prices, discount, seller, SKU, image, category and availability - was 40 of 40 in all six categories.

Yes, and only that filter is offered, because it is the only one that works. Asking for one through five stars really narrows the set: on a product with 7,046 reviews the counts come back as 74, 63, 135, 726 and 6,048, and the returned pages carry only that rating. Several other review filters that Tiki appears to accept change nothing at all, so this API does not expose them. Note that Tiki publishes three different review counts for the same product - 6,153 on the product record, 7,046 on the review stream and a histogram summing to 7,029 - and the API returns all three under separate names rather than picking one.

There is no questions-and-answers feed, no price history, no stock by delivery area and no order data - Tiki does not publish them. Facets are a category feature, so include_facets has no effect on a keyword search. Tiki's own meta title and description fields are empty on every product measured, so they are not returned. And the search row's product name and the product record's name can differ, because Tiki publishes both: on 10 products checked, 9 matched and 1 differed, where the listing carried the full seller title and the record carried a shorter one. Each action returns the name its own source publishes rather than one being silently overwritten.

Tiki API is a ReefAPI endpoint group for vietnam's home-grown marketplace: prices in vnd with the strikethrough kept apart, per-seller offers, variants and reviews with the star histogram. It returns live JSON through POST requests under /tiki/v1.

Yes. ReefAPI starts with 1,000 free credits, no card required. Tiki calls use the same shared credit balance as every other ReefAPI engine.

No login to Tiki is needed for the API response. You call ReefAPI with your x-api-key header, and the playground can run live examples before you create a production key.

The page example is captured from a live search call, and production requests fetch live data through ReefAPI rather than a static sample.

Tiki actions currently cost 1-2 credits per successful call. Failed or blocked calls are free. All APIs draw from one credit pool.

Yes. Connect ReefAPI once through MCP and your assistant can call tiki actions with the same key, credit pool and JSON envelope used by normal REST requests.