GameCore Product API — wholesale game top-ups over one API

One REST API over an aggregated catalog of game currency, gift cards and keys. You read the catalog, you place orders against your own balance, and you get the result back — a key, a code, or a top-up credited straight to a player's account. Your buyers never see us: you sell under your own brand, at your own prices, on your own site.

These pages describe the API as it behaves today, verified against the running code rather than against a plan. Access is issued at onboarding — there is no self-service sign-up form here — and the fastest way to start is Quickstart.

What you are integrating with

Think of us as a warehouse, not as a payment provider. We hold the stock and the supplier relationships; you hold the storefront and the buyer.

Three properties shape everything else:

• One catalog, several upstream suppliers. Games, categories and SKUs arrive from several sources and are normalised into a single model with a single set of endpoints. Which supplier fulfils a given SKU is our problem, not yours, and it is not exposed.
• One credential, one balance. Every call carries the same X-Api-Key header. Orders are paid from your prepaid Product API balance — never with a card and never by your buyer.
• Wholesale prices in USD. Every amount we return carries currency: "USD"; payment is USDT only. Every price is your final wholesale price (supplier wholesale + 5 %, rounded up to the cent) — there is no volume discount. You never send a price when ordering: the order body carries products and quantities only, and we price the order at the moment we create it. Pricing describes the public Product API formula.

There is no concept of "your buyer" anywhere in this API. There are no user accounts, no buyer logins, no per-buyer tokens. There is you, your balance and your orders.

Who does what

Two boundaries are worth stating plainly, because getting them wrong is expensive:

We validate the shape of delivery data, not the truth of it. Where a format rule exists for a game family we enforce it before charging you — digit counts, numeric-only fields, allowed select options. What we never do is check that the account exists or that it belongs to the buyer who paid. A well-formed ID belonging to a stranger is delivered to the stranger, and cannot be recalled. That is why ID entry and confirmation belong in your funnel; see Direct top-up API.

Our webhooks are for your backend, not for your buyer. They tell your system that an order resolved. What happens next — an email, a page in the buyer's account, a Telegram message — is yours to decide.

How an integration is shaped

The usual sequence, end to end:

1. Your buyer browses your catalog, which you keep in sync with ours.
2. Your buyer checks out and pays you, your way.
3. Your backend records its own order and then calls POST /b2b/orders with an X-Idempotency-Key.
4. We charge your balance and create the order in a single database transaction — either both happen or neither does — and hand back an order code.
5. We submit the order to the supplier. If they are unavailable, it goes into a retry queue; the order simply stays in processing meanwhile.
6. When the order resolves we deliver a signed webhook to your callbackUrl. If you would rather poll, the order endpoint is there too.

For the catalog itself, the shape that survives contact with production is a hybrid: keep game-level metadata locally and refresh it on a schedule, but read products lazily with a short cache, and re-read the product right before you create the order. Prices move with supplier changes, so a price cached an hour ago is a price you might not get. Catalog covers the endpoints and the cache windows behind them.

What this API does not do

Stated up front, because each one has cost somebody a sprint:

• No file uploads. SKUs whose delivery form asks for a screenshot or an image are excluded from the Product API catalog entirely, and an order for one is rejected.
• No sandbox on accounts set up by our team. There a test-prefixed key behaves exactly like a live one: real catalog, real balance, real supplier. A self-service account (register with Telegram) is different: its gc_test_ key runs on the test rail — orders are not sent to suppliers, nothing is charged, and the order completes immediately through a simulated supplier. No webhook is sent for test orders (a gc_test_ key on the test rail), even when callbackUrl is set — poll GET /b2b/orders/:code instead. A live key is issued after your first USDT top-up. See Authentication before you point a test suite at either.
• No cancel endpoint. Once an order is created it runs to a terminal state; there is no call that unwinds it.
• No price in the request. Sending one changes nothing — we price server-side, every time.
• No buyer-facing anything. No hosted checkout, no payment collection, no buyer notifications.

Where to start

Read in this order and you will have a working integration without backtracking:

1. Quickstart — five curl calls from an empty terminal to a live order.
2. Authentication — the header, the key types, and what 401 and 403 actually mean.
3. Catalog — games, categories, products, and what to store on your side.
4. Direct top-up API — delivery by UID or Player ID, the largest slice of the catalog.
5. Delivery types — the five values and what each one needs from you.
6. Orders — statuses, partial delivery, and what "stuck in processing" means.
7. Webhooks — the signed event channel and how to verify it.
8. Idempotency and errors — how to retry safely and how to read a failure.