Game Round API

Gamity provides a specific HTTP API designed for the reception of game rounds. While this API is one of the communication channels available for transmitting game rounds, there are other options as well. See more details here.

The API supports receiving both individual game rounds and batches of game rounds. For optimal performance, it is strongly recommended to send game rounds in batches.

Endpoints:

/gamerounds/{INTEGRATION_ID}/single: accepts an individual game round.
/gamerounds/{INTEGRATION_ID}/batch: accepts a batch of game rounds in a single call (max 100 per batch).

Interactive swagger page of the API: Swagger UI

Example payload:

POST https://qa-ec1.transaction-api.gamity.io/gamerounds/{INTEGRATION_ID}/batch HTTP/1.1
Content-Type: application/json
X-API-Key: [ask from Codemodity]
 
[
  {
    "timestamp": "2022-04-30T04:03:10.200Z",
    "roundId": "f9c15be2-7164-11ed-a1eb-0242ac120002",
    "brandId": "superkingz",
    "playerId": "Player-4",
    "gameId": "EVO_ANDAR_BAHAR_1",
    "roundType": "REGULAR",
    "currency": "EUR",
    "betAmount": 2.5,
    "winAmount": 1
  }
]

Request parameters

The request URL requires an INTEGRATION_ID that is provided by Gamity and is used to identify a specific client and its environment.

parameter	type	required	description
`timestamp`	string	yes	UTC date and time of the round in ISO 8601 format.
`roundId`	string	yes	Unique round ID in the client’s system. It is used for idempotency checks.
`brandId`	string	yes	The unique id of a brand the player belongs to (e.g. HAPPYLUKE). `brandId` and `playerId` together should be unique.
`playerId`	string	yes	The id of the player in the brand/PAM system. `brandId` and `playerId` together should be unique.
`gameId`	string	yes	The unique id of the game accross all game providers.
`roundType`	string (enum)	yes	Can have dynamic values based on the client’s system and the type of rounds we would like to distinguish, e.g. regular rounds vs Bonus Buys. By default it should be “REGULAR”.
`currency`	string	yes	The currency of the round. Gamity automatically converts this amount internally when needed (e.g., for minimum bet checks in the tournament’s base currency).
`betAmount`	decimal	yes	Total bet amount within the round.
`winAmount`	decimal	yes	Total win amount within the round.

Response and error handling

Standard HTTP status codes indicate the result of the request.
Idempotency check, due to possible retries, is based on the roundId field.

Status code	Description	Retry?
200	“OK”, the payload format was correct, but was ignored as deemed irrelevant for the tournaments (e.g. the game round belongs to inactive brand).	No
202	“Accepted”, the game round was accepted and sent for processing.	No
4xx	Client error; the request contains bad syntax or cannot be fulfilled. The response body should contain some indication of the nature of the issue (e.g. missing field or player does not exist).	No (maybe manual)
5xx	Server error; the server failed to fulfill an apparently valid request.	Automatic until HTTP 200/202 (with a graceful backoff schedule)
Timeout	The request failed due to a network issue.	Automatic until HTTP 200/202 (with a graceful backoff schedule)

Authentication

The API uses API keys to authenticate requests. All API requests must be made over HTTPS. Calls made over plain HTTP will fail. API requests without a valid API key will also fail. API keys are determined by Gamity and shared with the client tech team via a secure channel.

IP Whitelisting

For improved security production endpoints are protected by IP whitelisting. These are TBD before going live.

Overview Payouts (API)