GGsel Seller API — Automation Options
Running a GGsel storefront by hand hits a ceiling around a hundred SKUs: stock drifts, prices go stale, and a buyer waiting for a code at three in the morning does not care that you were asleep. Automation here is not about architectural elegance — it is about not paying in money and rating for every human delay. This guide covers what can actually be automated, where the programmatic layer lives, which architecture to pick, and which failures you must design for up front.
It is technical but readable without prior integration experience. If you are starting from zero, read the API quickstart first.
Where the API actually lives
GGsel as a storefront sits on Digiseller infrastructure — that layer handles payment acceptance, product cards and automatic delivery of digital goods. Practically, this means a seller's programmatic capabilities are defined by that layer rather than by a separate "GGsel API" product.
Rule one follows: do not design your integration from forum posts and blog articles. Method sets, authentication schemes and rate limits change. Confirm current documentation on the platform side before you start, and again after any major release on their end.
Rule two: start with one SKU. A full cycle — order, delivery, status, dispute — on a single product exposes every bottleneck far more cheaply than migrating a thousand-item catalogue.
What is worth automating
Stock synchronisation
The highest-return automation. Selling something you do not have means a dispute, a refund and a rating hit. The logic is simple: supplier stock changes, your middleware updates availability on the marketplace. In practice:
- Pull items early, not at zero — keep a buffer.
- Distinguish "out of stock" from "connection failure". On a supplier timeout, hiding the listing beats selling something you cannot fulfil.
- Log every change — you will need the history when a dispute is reviewed.
Price synchronisation
Cost prices move, retail must follow. Automation computes price from cost using a formula that accounts for the marketplace fee, payment processing and withdrawal costs — take the actual rates from the platform's current tariff page, because they change and must never be hardcoded as constants. Always enforce a margin floor: if the computed price falls below minimum viability, the item is pulled rather than sold at a loss. The method is in reseller unit economics.
Auto-delivery of codes
Two approaches:
| Approach | How it works | Upside | Downside |
|---|---|---|---|
| Uploaded pool | Codes pre-loaded into the card | Simple, independent of your service | Manual topping up, can run dry |
| External issuance | Code requested from your middleware on payment | One pool serves all marketplaces | Requires high service availability |
A hybrid is common in practice: a small buffer pool as insurance plus external issuance as the primary path. General principles are covered in automating digital code delivery.
Order status
Payment, delivery, dispute, refund — each event should land in your system without anyone opening the seller dashboard. It is the foundation for both support and financial reconciliation.
Architecture: supplier, middleware, marketplace
The only pattern that holds up looks like this:
Supplier API → your middleware → marketplace
The middleware is your service. It holds the normalised catalogue, the mapping between supplier SKUs and marketplace cards, pricing rules, an order journal and an event queue.
Why you cannot wire supplier straight to marketplace:
- No single journal. During a dispute you cannot prove which code went with which order.
- No pricing rules. Markup, margin floor and rounding have nowhere to live.
- No multi-marketplace path. A second storefront requires a second identical wiring job.
- No failure control. Retries, idempotency and graceful degradation can only be implemented on your side.
With multiple sources you also need routing — which supplier fulfils a given SKU on a given order. That is a topic of its own, covered in multi-source fulfilment routing.
Idempotency: the mandatory minimum
Networks lose responses; marketplaces and suppliers retry. Without protection, a repeated issuance request burns a second code: the buyer receives one and you pay for two.
The working contract:
- Every marketplace order maps to a stable idempotency key in your system.
- All outbound supplier requests carry that key.
- The middleware persists the issuance result and replays the same code on a repeat rather than calling the supplier again.
- The key lives long enough to outlast any reasonable retry window.
Edge cases and common mistakes are in the idempotency keys deep dive.
Webhooks: how not to lose events
The rules are simple and almost universally broken:
- Verify the signature before any processing.
- Acknowledge fast — accept, enqueue, return success. Synchronous business logic inside the handler produces timeouts and a retry storm.
- Treat delivery as unordered and not guaranteed. Store an event ID, drop duplicates, never rely on sequence.
- Keep an API reconciliation job as a safety net: periodic status polling catches what fell through.
The full treatment is in webhook integration.
Failure modes you must design for
| Failure | What happens | Mitigation |
|---|---|---|
| Supplier stockout | Order paid, no code available | Fallback source, auto-delist, prepared buyer message |
| Issuance timeout | Unclear whether a code was consumed | Idempotent retry, then reconcile by key |
| Duplicate webhook | Order processed twice | Deduplicate on event ID |
| Price drift | Sale below cost | Margin floor plus automatic delisting |
| Code revocation | Dispute after delivery | Issuance journal, warranty claim to the supplier |
None of these are exotic — they all happen routinely, and the difference between a calm business and a painful one is whether the handler was written in advance. Stockout recovery is covered separately in supplier stockout recovery.
Where the inventory feed comes from
Automation only pays off on top of a supplier with a predictable programmatic interface. FoxReload provides exactly that surface: 900+ SKUs across games, gift cards, top-ups, eSIM and software, a single REST API with auto-delivery and multi-region SKUs — one source your middleware connects to instead of a dozen manual channels. For how to choose a source and what to demand in writing, see where GGsel sellers source game keys.
And to repeat the important part: platform methods, limits and requirements change. Verify current Digiseller documentation and GGsel rules before you build, rather than porting an old integration untested.