Browse and search products

This field only ever comes back as false (confirmed out of stock) or null (not checked against the source). There is no true — treat it as a value that does not exist rather than one you are waiting for. Catalogue endpoints answer from data the shop already holds; they do not query the source on every call, so most products come back as null, which is the truth: nobody checked that product's stock on this pass. Never test available === true, and never write a condition like not true means sold out — reading it that way hides nearly the whole catalogue, products that really are for sale, from your own storefront. Hide only the ones that are false. Real stock is checked against the source again when the order is placed, which is the only point at which an answer about availability is dependable.

price is the number of baht this key pays, not the shop's shelf price, and discount_percent says how many percent already came off the shelf price. Taking your discount off it a second time produces a price the system will never accept, and then every order is refused on price with nothing to tell you why. Your discount is set as a single number, but each product type has a cap of its own; the discount actually applied is whichever of your tier and that cap is smaller, and you can read the already-resolved value per type from GET /api/v1/me in the discount.effective_percent field — do not compute prices on your side from the raw discount number. Prices also move all the time, both with what a product costs us and with the shop's own pricing: store them for as long as you like, but always re-read the price immediately before ordering.

On top of the discount cap there is a per-product price floor: if the discounted price would fall below what that product costs us, we raise the price back up to that cost (but never above the shelf price) and report discount_percent as the discount you actually got, which is less than the cap. GET /api/v1/products does not apply that floor, so prices in the list are approximate and can be lower than the price the system will accept. Before ordering, confirm the price with GET /api/v1/products/{product_id} for cdkey and account1, or with GET /api/v1/products/{product_id}/items for account2, and send that value as expected_price with the order. A price that does not match what the system computes at order time is rejected, not silently adjusted.

A starts-with search cannot use a position marker alongside an ordering on another field, so there is no paging within a search at all. Sending search and cursor in the same request is refused with 400 cursor_with_search rather than answered, precisely because the older behaviour — quietly ignoring the cursor — left a sync loop running for ever over the same set with no error status and no field telling it what had happened. A search therefore returns one page: everything that matched, up to the cap reported by search_capped. If that cap was hit, search again with a longer, more specific term; do not try to page past it. To sync the whole catalogue, walk cursor without search, one platform at a time.

The five refusals at the authentication gate — invalid_key (401) · key_revoked (401) · insufficient_scope (403) · quota_exceeded (429) · too_many_inflight (429) — can happen on every endpoint, this one included, because they are thrown before the request reaches a single line of this endpoint's own logic (the scope it needs is the one declared at the top of this page). The response tabs above therefore list only what this endpoint itself answers; that is not a claim that those five cannot happen here. All of the detail lives in one place, on the identity endpoint page at /developers/access/me: the HTTP status of each one, which of them spend your daily quota, which headers come back, and why the two 429s need opposite handling. It is deliberately not copied onto every page, because the second copy is the one nobody remembers to update the day the rules change.