Reseller API

Make this your first request after receiving a key, to confirm the key really works. It also answers the four things the rest of these docs assume you already know: **what this key is allowed to do** (`scopes`) · **how much money your wallet holds and in which currency** (`wallet`) · **what discount you actually get, per product type** (`discount`) · **how many requests you have left today** (`quota`). ⚠️ There is **no sign-up, no test key and no sandbox**: keys are issued by the shop's admin only, every request from here on runs against the live system, and every order spends real money.

Browse and search the catalogue, one platform at a time. Three things to know before you write any code: **(1)** `platform` is the only required parameter and there is no way to ask for every platform at once, so syncing the whole catalogue means looping platform by platform · **(2)** every product carries a `type` that decides how you order it — `cdkey` (a game key) and `account1` (a never-used account) are ordered with `product_id` alone, while `account2` (a pre-owned account) needs you to pick an individual account first and send its `item_id` too · **(3)** prices here are in Thai baht with your key's discount already taken off, **but they are not final**: this endpoint skips the per-product price floor, so a price here can be slightly lower than the real one — **always read the price from a single-item endpoint before you order.**

Get the latest details and **the real, orderable price** for one product. What you do next depends on the product's `type`. **`cdkey` and `account1`** — the `price` in this response is the value to send as `expected_price`, and `product_id` alone is enough to order with. **`account2`** — you cannot order from this page: one pre-owned product has many individual accounts for sale, each in different condition and at a different price, so go on to `GET /api/v1/products/{product_id}/items`, pick one account, and use that account's price and `item_id` instead.

See the individual pre-owned accounts genuinely on sale under one `account2` product, so you can pick one before ordering. **This endpoint is for `account2` only**: `cdkey` and `account1` are ordered with `product_id` alone and have nothing to pick from. Think of an `account2` product as a box holding many individual accounts, each with its own games, level and price. **The routine is: pick one entry, then send that entry's `item_id` and that entry's `price` as `expected_price` when you create the order — never the price of the product it sits under.**

Buy one product and pay for it out of your wallet. **`cdkey` (a game key) and `account1` (a never-used game account) are delivered straight away, inside this request.** **`account2` (a pre-owned account) is delivered later, over your callback or by reading the order again**, because the account has to be checked before we buy it and that takes far longer than one request can wait, so this call only takes the order and queues it. Every reply carries an `order_id` — always keep it, because it is the only way back to the order. If a request times out or you are unsure it completed, send the identical request again with the same `request_id`, never a fresh one.

Read the state and the result of one order. **This is the source of truth for order state**, so check here rather than relying on callbacks alone: a callback is a convenience that tells you when something changed, but if one never reaches you the real answer is still readable here. Three fields carry the whole answer: `status` = how far the order has got · `charged` = whether the wallet was actually charged · `delivery` = the goods, which appear once `status` is `completed`. The shape of `delivery` depends on the `type` of that order — `cdkey`/`account1` return keys, `account2` returns account credentials.

See your most recent orders, up to 100, newest first. **This is not your full order history and it should not stand in for a database on your side**: it has no filters, no paging, and anything older than the last 100 orders cannot be reached through it again. The right pattern is to **store every `order_id` on your side when you place the order**, then read them one at a time with `GET /api/v1/orders/{order_id}` when you reconcile. Use this list to eyeball what happened recently, or to hunt down an order whose `order_id` you genuinely lost.

Set, change, or disable the URL we notify when an order reaches a final state · **This page covers registering the endpoint only**; what the call we send you looks like, how to verify its signature, and how retries work are on the callback page (`/developers/webhooks/callback`) · An endpoint belongs to **one API key**, not to your account, so if you use several keys you register one endpoint per key

When an order reaches a final state — delivered, failed or refunded — we `POST` it to the URL you registered, as a whole order object with a signature you can verify came from us · Your endpoint has to do three things, in this order: **(1) verify the signature against the raw body before parsing it → (2) answer 2xx as fast as you can → (3) then do the work, keeping it idempotent on `order_id`** · ⚠️ A callback is a convenience notification, **not the source of truth**: your system has to stay correct even if not one of them ever arrives (see the warnings at the end of this page).