Integration Checklist

Use this checklist when connecting an operator backend to Aggregator or moving from demo testing to production. It brings together the existing command, wallet, billing, and recovery requirements; it does not grant provider access or a gaming licence.

Use the integration handbook for the prerequisite reading sequence and the integration-model comparison when evaluating direct provider connections, aggregation or a supplied website.

1. Define your integration and operator responsibilities#

Confirm which games, currencies, territories, and provider connections your business may use. An advertised provider, a catalogue entry, or a turnkey website category is not proof of production entitlement. The command API does not currently launch 9Wicket.

Your operator remains responsible for player identity and age checks, permitted markets, responsible gaming, player payments, and applicable regulatory obligations. Review the service terms, responsible gaming principles, and turnkey website guide if you are evaluating Business Launch.

2. Prepare backend authentication#

Create an Application API Key in your workspace and configure the required method scopes, expiry, and egress-IP allowlist. Keep keys and callback secrets on your backend, outside browser code, source control, shared screenshots, and support tickets.

Requests use POST https://aggregatornetwork.com/v1/commands, X-API-Key, and a JSON body. See getting started and request validation. Sandbox/demo access still requires an authorised key and workspace entitlement; account creation alone does not confirm game access.

3. Discover the actual game catalogue#

Call getGameList for an enabled uppercase three-letter currency and retain the returned game identifier. Do not guess identifiers from a provider name, logo, or game title. Catalogue discovery is read-only and rejects the Idempotency-Key header.

{
  "method": "getGameList",
  "currency": "USD"
}

USD is illustrative; use a currency enabled for your workspace and the selected provider/game. Availability can change, so refresh catalogue records and handle a later launch rejection. Read provider and currency access and catalogue responses.

4. Test demo launches and response handling#

Use getGameDemo only for titles supporting trial play. Omit the player, starting balance, and idempotency header. Demo sessions do not deliver monetary settlements or fund player wallets.

Check both HTTP success and numeric error: 0 before using a launch URL. An application rejection may use HTTP 200 with a nonzero numeric error. Gateway failures use an error object with a code and request ID. Never construct a provider launch URL yourself or publish a temporary URL in logs. Compare demo launch requirements and response formats.

5. Reserve player funds before a real-money launch#

Your system owns the player wallet. Reserve the requested starting funds before dispatching getGame. Persist the exact request, player/currency/session association, and one idempotency key before sending it. The starting balance is a finite JSON number within the documented range.

Configure the callback URL, signing secret, and both exact HTTPS return origins. A wallet settlement callback is not a generic per-bet balance-query endpoint: this API starts the session with the supplied balance and delivers documented settlement events afterwards. Implement the actual launch contract and settlement contract.

6. Validate settlement and callback recovery#

Verify x-callback-signature against the exact delivered body bytes before parsing or processing. The signature is an HMAC-SHA256 using your callback secret. Deduplicate by the body serial_number and durably store the event and wallet/bookkeeping change atomically, or durably enqueue it before responding with HTTP 2xx.

Preserve decimal amounts. Treat credit_amount as the authoritative post-round player balance; do not rebuild it by subtracting bets from wins. Retain launch records when a callback omits currency or session context, and prevent older snapshots from overwriting a newer balance.

Test duplicate and concurrent delivery, a failed signature, delayed/out-of-order events, and receiver downtime using your own controlled test environment. Never inject fabricated transactions into a live account to test this checklist.

Delivery has three total attempts. Manual retries require eligibility, callback-management permission, and recent MFA authentication; delivered, unknown, in-flight, or exhausted events cannot be blindly retried. Follow delivery recovery and idempotency guidance.

7. Check activation and separate GGR funding#

Pricing distinguishes the one-time activation payment from GGR wallet funding. Sandbox permits demo testing. Real-money launches require production activation, provider/game/currency enablement, a positive funded GGR wallet, and the usual key, callback, and return-origin checks.

Upgrade checkout credits prior confirmed activation payments. Creating payment instructions does not confirm payment or activate a package. Review the GGR wallet guide before funding.

GGR fees are calculated independently per provider and play currency per UTC calendar month as max(bets - wins, 0) × rate. Negative GGR does not offset another provider/currency or carry forward. The platform funding wallet remains separate from player funds.

8. Use backend examples and Postman safely#

The PHP, Node.js, and Java examples show the launch request and success checks. Postman can help inspect a catalogue response before you implement backend code:

1. Create a private local request using the documented command endpoint and headers, or inspect the public OpenAPI specification.
2. Keep the API key in Postman Vault or another locally managed secret value; do not export it in a collection or sync it into shared environments.
3. Send the read-only catalogue body above without an idempotency header.
4. Compare the HTTP status, numeric application error, response fields, and x-request-id.
5. For mutations, persist one key and the exact operation before dispatch. Do not configure a runner to generate a new key for every retry.

An example or successful demo request does not validate a production wallet implementation. Complete your own transaction, failure, and reconciliation tests before launch.

For Postman's local secret-storage behavior, see its official Vault documentation.

9. Launch with an operational handover#

Keep request IDs, timestamps, launch records, callback serial numbers, and reconciliation decisions accessible to your authorised team. Configure staff permissions and escalation for unknown outcomes. Confirm your approved providers, funding, return origins, and recovery procedure before enabling players.

For help, use portal support or contact the integration team. Include non-secret request references and a concise failure description. Do not send API keys, callback secrets, passwords, or temporary launch URLs. You can also reply to our support email; keep the eight-digit ticket number in the subject to continue the same conversation.