Skip to Content
Introduction

Introduction

Welcome to 7SoftTech Seamless API documentation!

Terms

TermDescription
Casinothe operator who works with the players
Game providerthe final content provider
PROVIDER_URLgames content provider api endpoint
WALLET_URLwallet server api endpoint
CASINO_IDcasino’s identifiers
AUTH_TOKENAPI key sent in the X-API-KEY header of every request the casino makes to PROVIDER_URL
CALLBACK_SECRETshared secret used to sign the callbacks made to WALLET_URL, see Signed wallet callbacks

Before integration

  1. Provide your Project Name and WALLET_URL to us.
  2. PROVIDER_URL, WALLET_URL, CASINO_ID and AUTH_TOKEN will be provided by one of our managers.
  3. Implement the API Methods you call and the API Callbacks you answer.
  4. We run the certification suite against your WALLET_URL and send you the report. Go-live follows from a clean run.

All API Methods live under /v2/ on PROVIDER_URL. There is no other version to choose from — everything in this documentation describes the current API.

The v1= prefix on the X-Signature header below is not an API version. It names the signature scheme, so a future scheme can be rolled out next to it, and it stays v1 whatever the API version is. Send it exactly as shown.

Security

The two directions of traffic are authenticated differently — do not mix them up when implementing either side.

API calls to PROVIDER_URL

The API Methods you call on PROVIDER_URL are authenticated with an API key (AUTH_TOKEN), issued together with the rest of your credentials before the integration starts.

  • Send the key in the X-API-KEY header of every request:
X-API-KEY: {AUTH_TOKEN}
  • The key is a shared secret: keep it server-side only, never expose it to the player’s browser or to the game client. If it leaks, ask us for a new one.
  • A missing or wrong key is answered with HTTP 401. A valid key from an IP that is not on your allow-list is answered with HTTP 403.

Callbacks to WALLET_URL

The API Callbacks we send to your WALLET_URL do not carry X-API-KEY — that header only applies to the direction above. See Signed wallet callbacks below for how to authenticate this direction.

Do not rely on X-API-KEY to authenticate incoming wallet callbacks — we never send it on this path. Use the callback signature described below, and keep an IP allowlist as a second layer regardless.

Signed wallet callbacks

Every callback to WALLET_URL — authenticate, balance, bet, win, cancel — can be signed with HMAC-SHA256, using a CALLBACK_SECRET issued to you separately from AUTH_TOKEN. Ask your account manager whether signing is enabled for your integration.

Headers

HeaderExampleMeaning
X-Casino-Id1000your CASINO_ID — which secret was used to sign
X-Timestamp1754380800unix seconds at signing time
X-Nonced1e2f3a4b5c60718293a4b5c6d7e8f9016 random bytes, hex-encoded
X-Signaturev1=9a5844bb...the signature scheme (always v1, unrelated to the API version) and the digest

Wire format

  • Signed POST: [POST] {WALLET_URL}/ with the parameters documented on each callback page as a JSON object body, plus the headers above.

Signature

signing string = "{X-Timestamp}.{X-Nonce}.{payload}"
payload        = the raw request body, exactly as received
X-Signature    = "v1=" + hex(hmac_sha256(signing string, CALLBACK_SECRET))
                  ^^^^ the signature scheme, not the API version — always this literal

Compute the signature over the payload exactly as received — do not re-encode or re-order the JSON body. There is no canonicalization step on our side, so none is needed on yours.

What to verify

All four checks are required — skipping any one of them leaves a gap:

  1. Signature — recompute it and compare with a constant-time function (e.g. PHP’s hash_equals), never ==.
  2. Timestamp — reject if abs(now - X-Timestamp) is more than 300 seconds.
  3. Nonce — reject an X-Nonce you have already seen; cache seen nonces for at least 300 seconds (a 600 second TTL gives comfortable margin).
  4. transaction_id — a repeated transaction_id must return the original result, not apply the callback again. We retry transient failures, so a duplicate is a normal event, not an attack — see the note on Bet.

Keep your existing IP allowlist too; the signature does not replace it.

Test vector

Reproduce this to confirm your implementation is compatible before we enable signing for you:

CALLBACK_SECRET = 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
X-Timestamp     = 1754380800
X-Nonce         = d1e2f3a4b5c60718293a4b5c6d7e8f90
payload         = {"user_id":42,"action":"bet","amount":1.50,"currency":"EUR","transaction_id":"tx-1001"}

X-Signature     = v1=d4260b8eea5cce8da2244166b2e4d1dff47ef11f37c3b173333c168b94d026dd
printf '%s' '1754380800.d1e2f3a4b5c60718293a4b5c6d7e8f90.{"user_id":42,"action":"bet","amount":1.50,"currency":"EUR","transaction_id":"tx-1001"}' \
  | openssl dgst -sha256 -hmac '0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'

A rejected signature is entirely your endpoint’s decision — reject it the same way you already reject an unrecognized request (e.g. HTTP 401). We do not require a specific error body on this path.

Request and response format

  • API Methods are called by the casino on PROVIDER_URL. rungame, create-freespins and cancel-freespins are POST requests with a JSON object body; the rest are GET requests with query parameters.
  • API Callbacks are called by the game provider on WALLET_URL as POST requests with a JSON object body.
  • Every response, in both directions, is a JSON object.
  • Monetary values use two different units, so watch out when mapping them:
    • callback amount and balance fields are decimal values in the major currency unit (for example 0.25 = 25 cents),
    • the Gift Spin bet parameter is an integer in cents.
  • Every callback must return either the documented success payload or an error response.

Workflow

Workflow

Last updated on
Gamelist