GameCore Supply 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 B2B balance — prepaid, or on credit up to an agreed limit — never with a card and never by your buyer.
• Wholesale prices in rubles. Every price we return is your account's wholesale price in RUB — the list price before your volume tier. The tier discount is applied when an order is created, to every line of it, so the amount charged can be lower than the sum of the catalog prices you read a second earlier; no catalog response ever shows it. 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 tiers.

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 the exchange rate and 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 B2B catalog entirely, and an order for one is rejected.
• No sandbox on /b2b/*. A test-prefixed key behaves exactly like a live one here: real catalog, real balance, real supplier. See Authentication before you point a test suite at it.
• 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.