Skip to main content
Every request in the GitSlotPark Seamless Wallet API — whether you are calling GitSlotPark or GitSlotPark is calling you — must include a sign parameter in the JSON body. This signature lets each party verify that a request was sent by a legitimate counterpart and has not been tampered with in transit.

​
How signing works

The sign value is the HMAC-SHA-256 digest of a concatenated string of the request’s parameters, computed using your secret key. The output is 64 uppercase hexadecimal characters. Formula: 
sign = HMAC-SHA256(secretKey, param1 + param2 + ... + paramN).toUpperCase()
The parameter concatenation order is fixed per endpoint. The correct order is specified in each endpoint’s reference page. If you concatenate parameters in the wrong order your signature will be rejected.
The secret key is associated with your licensee account and is provided by GitSlotPark during onboarding. Your agentID is your Partner ID, also assigned by GitSlotPark.

​
Rules for computing the sign

Follow these rules exactly to produce a valid signature:
  • Concatenate directly — join parameter values one after another with no separator characters between them.
  • Use UTF-8 encoding for both the key and the message.
  • Format amounts to exactly two decimal places — use 12.30, not 12.3 or 12.300. A malformed amount will produce the wrong signature and will also fail server-side validation.
  • Output in uppercase — the resulting hex string must be all uppercase.
  • The computed digest is always 64 characters long.
Never send your secret key in a request. It is used only locally to compute the sign value. Store it in a secrets manager or environment variable and keep it out of source control.

​
Invalid sign errors

If the sign you send does not match what GitSlotPark computes on its side, the response will contain result code 3: 
{
  "result": 3
}
When you receive result code 3, check the following:
  • Parameter concatenation order matches the endpoint specification.
  • No extra whitespace or separator characters between concatenated values.
  • Amount fields are formatted to exactly two decimal places.
  • The correct secret key is being used.
  • Both key and message are encoded as UTF-8 before hashing.

​
Code examples

public static string GetSign(string key, string message) {
    System.Security.Cryptography.HMAC hmac =
        System.Security.Cryptography.HMAC.Create("HMACSHA256");
    hmac.Key = System.Text.Encoding.UTF8.GetBytes(key);
    byte[] hash = hmac.ComputeHash(System.Text.Encoding.UTF8.GetBytes(message));
    return BitConverter.ToString(hash).Replace("-", "").ToUpperInvariant();
}

​
Test vector

Use the following known-good inputs and expected output to verify your implementation before testing against the live API. Inputs:
ParameterValue
agentIDPartner01
userIDPlayer01
amount12.30
transactionID474e1a293c2f4e7ab122c52d68423fcb
roundIDab9c15f2efdd46278e4a56b303127234
Secret key1234567890
Concatenated message (values joined in the order shown above, no separators): 
Partner01Player0112.30474e1a293c2f4e7ab122c52d68423fcbab9c15f2efdd46278e4a56b303127234
Expected sign: 
475D834ACC3AB61D7DF4EA42751C6275387BC1787A098D2D0E091698D9BF2043
Run this test vector in your development environment before making any live API calls. If your output matches exactly, your signing implementation is correct.

​
Signing callback requests

GitSlotPark signs every callback request it sends to your service using the same HMAC-SHA-256 algorithm. You should verify the sign parameter on all incoming callback requests to confirm they originate from GitSlotPark. Reject any request where the signature does not match — respond with HTTP 200 and result code 3.
CodeMeaning
3Invalid sign — the signature did not match
4Invalid agent — the agentID was not recognised
7Invalid API token — the apiToken was not recognised
For the full list of result codes, see Result codes.