How to Sign GitSlotPark API Requests with HMAC-SHA-256

Understand how to compute and validate the HMAC-SHA-256 signature required on every GitSlotPark API request, including parameter order and formatting rules.

Every request exchanged between your system and GitSlotPark — in both directions — includes a sign field. This signature lets both parties verify that a request was sent by the expected party and that its parameters were not modified in transit. If the signature does not match, the server rejects the request with result code 3 (Invalid Sign).

How the signature is computed

The sign value is an HMAC-SHA-256 digest of a concatenated string of request parameters, encoded as a 64-character uppercase hexadecimal string.

1. Gather the parameters in the correct order

   Each endpoint defines a specific parameter concatenation order. The order is documented in the API reference for that endpoint. Use exactly the parameters listed — no extras, no omissions.

2. Format values correctly

   Before concatenating, apply these formatting rules:

   • amount must always have exactly two decimal places: 12.30, not 12.3 or 12.300.
   • All other string values are used as-is.
   • Concatenate the values directly with no separator between them.
3. Compute the HMAC-SHA-256 digest

   Using your secret key (provided by GitSlotPark), compute an HMAC-SHA-256 over the UTF-8 encoded concatenated string. The key is also UTF-8 encoded.

4. Encode as uppercase hex

   Convert the raw digest bytes to hexadecimal. The result must be uppercase and exactly 64 characters long. Include the sign value in your request body.

Formatting rules

Getting the sign wrong is the most common integration issue. Pay close attention to these rules before you write any code.

Rule	Correct	Wrong
amount always has 2 decimal places	12.30	12.3, 12.300
Parameters are concatenated without separators	Partner01Player01	Partner01,Player01
Hex output is uppercase	475D834A...	475d834a...
Key and message are UTF-8 encoded	key.getBytes("UTF-8")	default charset

Test vector

Use the following example to verify your implementation before going live.

Parameter	Value
agentID	Partner01
userID	Player01
amount	12.3 → formatted as 12.30
transactionID	474e1a293c2f4e7ab122c52d68423fcb
roundID	ab9c15f2efdd46278e4a56b303127234

Concatenated string:

Partner01Player0112.30474e1a293c2f4e7ab122c52d68423fcbab9c15f2efdd46278e4a56b303127234

Secret key: 1234567890

Expected sign:

475D834ACC3AB61D7DF4EA42751C6275387BC1787A098D2D0E091698D9BF2043

Run this test vector in your chosen language before integrating a live endpoint. If your output does not match exactly — including case — check your encoding, decimal formatting, and parameter order.

Code samples

C#

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();
}

Common mistakes

The following mistakes all produce an Invalid Sign error (result code 3):

• Lowercase hex output — the sign must be uppercase. Use .toUpperCase(), ToUpperInvariant(), or strtoupper() as appropriate for your language.
• Incorrect decimal formatting — always format amount to exactly two decimal places before concatenating. A value of 12.3 must become 12.30.
• Wrong parameter order — the concatenation order is defined per endpoint in the API reference, not alphabetically. Double-check the order for each endpoint you implement.
• Extra separators — do not add commas, spaces, pipes, or any other character between parameter values when concatenating.
• Wrong encoding — both the key and the message must be UTF-8 encoded before hashing. Avoid relying on a platform’s default charset.