Product

Sweepstakes Casino API

A single REST API that adds a full sweepstakes product to a platform you already run. Dual-currency wallet contract, 25,000+ titles from 160+ studios, coin-purchase flows, AMOE handling and state-level access control.

You stay the wallet of record and keep your own front end, PAM and player data. We supply the sweepstakes layer behind it. If you would rather we ran the whole platform, that is a different product — see full platform.

Get sandbox access Book a demo

REST over HTTPS · seamless wallet · same-day sandbox access · 99.9% uptime SLA

Example: opening a game session and settling the first bet through the wallet callback
POST /games/openGame
Content-Type: application/json
X-Signature: 9f0c4e2b7a1d6c3f8e05b492d7a1c6f3e8b04d29c7a1f6e3b8d05c294a7f1e6b

{
  "user_id": "481e3c9b-77f2-4d1a-b832-9c5e0f8a2d14",
  "player_login": "plr_8f31c2",
  "gameId": "aggregator:studio:starlight_reels",
  "currency": "SC",
  "demo": "0",
  "language": "en",
  "exitUrl": "https://brand.example/lobby",
  "callbackUrl": "https://brand.example/api/wallet"
}

200 OK
{
  "status": "success",
  "error": "",
  "content": {
    "game": { "url": "https://play.example/g/starlight_reels?session=7d3b9e2a" },
    "gameRes": { "sessionId": "7d3b9e2a-4f1c-8d06-a912-c3e5f7b29041" }
  }
}

Full API reference

What the API gives you

Six capability domains, one set of credentials, one integration. Take all of it or only the parts your platform is missing — every domain is independently switchable.

Domain What you call What it does
Wallet You expose one signed callback URL; we call it getBalance, writeBet and rollback against your ledger, with the session’s currency on every call
Games GET /users/{user_id}/getUserGames/{currencyISO}
POST /games/openGame		 25,000+ titles from 160+ studios — slots, fish games, table games, live dealer — fetched as a catalogue and opened per session
Coin purchases Back-office configuration Coin packages, pricing and offers, configured and granted through your ledger — the payment rails behind the purchase are yours
Redemption Back-office configuration Thresholds, holds and per-state redemption settings configured with us — the redemption itself, the verification and the audit record are yours, because the ledger is
AMOE Back-office configuration Postal, web-form and promotional entry grants, logged and auditable
Compliance Back-office configuration Per-state rules and redemption limits configured with us and changed without a release on your side — on this route your platform reads them and enforces them

The wallet contract

The integration is a seamless (single-wallet) model. Your platform stays the wallet of record — we never hold player balances. Game rounds settle in real time against your ledger, and the session’s currency travels with every call, so a Gold Coin round and a Sweeps Coin round are distinguishable in your data from the first transaction onward.

You expose one HTTPS endpoint. We post three commands to it — getBalance, writeBet and rollback — each signed, each carrying the game session. You answer with the player’s balance. That is the whole contract.

getBalance

Returns the player’s current balance in the session currency. Called at launch and on reconnect, so it shapes perceived load time more than any other call. If you cannot answer it, return a failure rather than a cached or default figure — a wrong balance here starts a round you may not be able to honour, and the round will not be started if this call fails.

writeBet

Settles a round. Unlike a classic four-endpoint wallet, bet and win arrive in the same call: bet is the stake to deduct, win the amount to credit, and either may be zero. round_finished tells you whether more calls are coming for this round. Return the balance after you have applied the operation, never before. If the player cannot cover the stake, reject the call rather than settling into a negative balance.

transactionId is the idempotency key. A repeat of an id you have already applied must return success with the current balance and change nothing — retries are normal, double-charges are not. One practical note: some studios send bet and win as numbers and some as strings. Parse defensively.

rollback

Reverses a settlement that could not complete, carrying the transactionId of the original call. Two rules matter more than the rest: restore the balance only once per transaction, and treat a rollback for a transaction you never received as a success rather than an error. Getting that second case wrong is the most common integration bug we see, and it only shows up under the network conditions that caused the rollback in the first place.

Verifying the signature

Every call carries an X-Signature header: a hex-encoded HMAC-SHA256 over the exact raw bytes of the request body, keyed with your secret. Compute it over the bytes as received — not over a re-serialised object, and not over pretty-printed JSON, or your signature will not match ours. Reject anything that fails verification before you look at the payload.

The rule that saves you a rewrite

Never let a game server hold balances. The moment Gold Coins and Sweeps Coins exist anywhere except your ledger, every report, redemption and audit inherits the ambiguity — and unwinding it later means a data migration under regulatory pressure. Read dual-currency wallet architecture before you design the schema.

How a round settles against the operator’s ledger The player acts in the operator’s front end. The operator’s platform calls openGame and receives a launch URL. The game runs on the remote game server, which posts getBalance, writeBet and rollback back to the operator’s own callback URL. The operator’s ledger answers with the balance. Balances never leave the operator. YOUR PLATFORM Player Front end Your ledger — wallet of record Your callback URL getBalance · writeBet · rollback CASINOAPI.TECH POST /games/openGame Game server studio content launch session signed callbacks How a round settles against the operator’s ledger Your platform calls openGame and gets a launch URL. The game server posts signed getBalance, writeBet and rollback calls to your callback URL, which answers from your ledger. Balances never leave your platform. Your platform front end · player data ledger — wallet of record openGame Launch API short-lived session URL Game server studio content Your callback URL getBalance · writeBet · rollback
Your platform stays the wallet of record. The game server never holds a balance — it posts signed calls back to you for every settlement.

Seamless wallet integration guide

Launching games

Fetch the catalogue once and cache it, then request a launch URL per session. The URL is short-lived and carries the currency context, so the same title runs as a Gold Coin game or a Sweeps Coin game without a second integration.

25,000+ titles from 160+ studios are available through the one connection: slots, fish games, table games, video poker, crash titles and live dealer. Adding a studio later is a catalogue change, not an integration.

  • One catalogue, two currencies

    Every title runs in GC and SC contexts from a single integration — the currency is a parameter on the session, not a separate connection.

  • RTP parity by default

    The same math model serves both currencies unless you deliberately configure otherwise — see RTP parity.

  • Studio-level reporting

    Player, currency, studio, title, stake and round are captured at the game-server boundary, so game-level analytics exist from day one.

Game aggregation

Coin purchases and redemptions

Coin purchases are a product sale, not a wager. On an API integration the purchase itself is entirely yours — your merchant account, your provider, your orchestration — and we are not in the flow. Packages, pricing and offers are configured in the back office and granted to the player through your ledger. If you have not started the acquiring conversation yet, high-risk acquiring is the part that takes longest.

Redemption runs the other way, with gates. Thresholds, holds and per-state limits are configured rather than coded, and the values live with us on either route. What acts on them here is yours: you hold the ledger, so you run the payout, you enforce the verification gate, and the audit record is yours to keep and to size.

Purchases

  • Coin packages and dynamic pricing
  • First-purchase and win-back offers
  • Your acquiring, your rails, your disputes

Redemptions

  • Thresholds and holds configured with us
  • Per-state redemption settings
  • Your verification provider, your gate
  • The payout and the audit record are yours

Coin packages Payments

Compliance you configure, not code

The US sweepstakes map moved repeatedly through 2025 and 2026, by statute in some states and by regulator enforcement in others. Teams that hard-coded their state rules have been rewriting them ever since.

Here the state rules live in the back office rather than in your codebase. Registration, play and redemption are governed independently per state, and changing a rule takes effect without a release on your side — which matters most in the weeks when the map moves faster than your release train.

  • State-level access control. Registration, play and redemption governed independently, per state.
  • One place to change a rule. Configuration rather than logic scattered through your codebase.
  • Verification. Your provider and your check, on either route. On the managed platform the gate is enforced for you; on an API integration the gate is yours, because the ledger is.
  • Auditability. On the managed platform every redemption is logged with the decision behind it. Here the record is yours — you hold the balances, so you hold the evidence.
See where sweepstakes casinos can legally operate Compliance hub

Informational only. Nothing on this site is legal advice — confirm your position with qualified US gaming counsel before launching in any state.

Reliability and security

Uptime 99.9% SLA — roughly 43 minutes a month — with status and incident history
Transport REST over HTTPS, TLS 1.2+, JSON request and response bodies
Authentication Bearer tokens for catalogue calls; X-Signature HMAC-SHA256 over the raw body on every game and wallet call
Idempotency Every settlement carries a transactionId; a repeat returns the current balance and applies nothing further
Environments Isolated sandbox and production, separate credentials, no shared data
Changelog Public and dated — see changelog

Uptime and SLA

What integration actually looks like

Sandbox credentials the same day you ask. Most teams reach a working wallet integration in a few days, and a full production launch typically runs 4 to 6 weeks once payments and legal are ready.

  1. Get credentials and read the reference

    Sandbox keys arrive same-day. The full reference, sample payloads and a Postman collection are public — no NDA, no sales call.

    Sandbox access

  2. Implement the wallet callback

    One endpoint handling three commands, with signature verification and idempotency on transactionId. This is the bulk of the work and usually the only part that touches your core ledger.

    Seamless wallet docs

  3. Wire catalogue, launch and coin flows

    Fetch and cache the catalogue, open sessions per player, then connect coin-package checkout and the redemption flow.

    Getting started

  4. Certify and switch to production

    Run the integration checklist, reconcile against a test round set including a forced rollback, then swap credentials.

    Integration checklist

Your team

  • The wallet callback and its ledger writes
  • Player identity and session management
  • Front-end lobby and game tiles
  • Payment method decisions

Our team

  • Content and studio relationships
  • The launch layer and game sessions
  • Coin flows and the currency context on every round
  • Compliance configuration and integration support

API only, or the whole platform

The API is the right choice when you already have a platform, a player base and a ledger you trust, and you want the sweepstakes layer without rebuilding any of it. It is the wrong choice if you would be building all of that from scratch just to hold the API.

API integration

You run
Platform, front end, PAM, ledger
We run
Content, launch, coin flows, compliance configuration
Best for
Existing casino or social operators, and teams with their own platform build

You are here

Full platform

You run
Your brand and your marketing
We run
Everything above plus PAM, back office, CRM, payments and front end
Best for
Operators launching without infrastructure

Sweepstakes casino software

Still weighing the models? Compare API, white label and turnkey

Questions engineering teams ask

Is this a seamless wallet or a transfer wallet integration?

Both models exist, and seamless is the one this page describes and the one we recommend. In the seamless model your platform stays the wallet of record and we call your callback URL in real time. A transfer model, where the game side holds a balance between sessions, is a poor fit for dual currency: the Gold Coin and Sweeps Coin distinction has to live in one ledger, and a transfer model puts a second one in play. See the seamless wallet guide.

What happens if a wallet call times out mid-round?

The round is settled by retry, not by guesswork. Every wallet call carries a transactionId, and a repeated call with an id you have already applied must return HTTP 200 with the current balance and apply nothing further. If the round cannot complete, we send a rollback carrying the original transactionId. A rollback for a transaction you never received should return success rather than an error, and a rollback you have already processed must restore the balance only once. Handling those two cases correctly is the single most common integration bug.

Do Gold Coins and Sweeps Coins need separate balances in my ledger?

Separate balances, one ledger. The game session is opened in a stated currency and every wallet call names it, so the two contexts never mix — but they should not live in two systems either. Dual-currency wallet architecture covers the schema implications.

Can I keep game providers I already have contracts with?

Yes. The integration does not require exclusivity, and operators routinely run our catalogue alongside direct studio integrations. What matters is that both paths settle against the same ledger with the same currency context, or your reporting fragments.

Do coin purchases go through us or through my own payment stack?

Either. You can use the coin-package flows and the rails we have configured for this category, or keep your own PSP relationships and simply grant coins through your own ledger. Most operators start with ours because the decline rates on coin purchases make orchestration worth outsourcing — see payments.

How do I control which states a player can play from?

State rules are configuration rather than code. Registration, play and redemption are governed independently per state and changed in the back office, so a regulatory change is a settings update rather than a release on your side. See geolocation controls.

What exactly does my endpoint have to return?

A small, strict JSON object: the balance after the operation has been applied, the currency, the player login, a status of success or fail, and an error string that is empty on success. Return HTTP 200 only when you have actually applied the operation. If the player cannot cover the bet, reject it rather than settling into a negative balance — and if a balance check fails, return an error rather than a cached or default figure, because a wrong balance starts a round you cannot honour.

Can I run several brands through one integration?

Yes — brands are a dimension on the integration, not separate connections. Catalogue, coin packages, bonus configuration and state rules can differ per brand while the wallet contract stays single.

Get a sandbox key today

Read the reference, send a signed test transaction, settle a round against your own ledger. Commercial terms come after you know the integration works — not before.

Get sandbox access Book a demo

Fields marked are required.