Each game developer has two ways of learning about matches for each user, but only one may be used at a time. In short, either OkLetsPlay can push that data into the game's back-end using a single HTTP endpoint or the game's back-end can query the data from the OkLetsPlay back-end. The first option is preferable and most efficient for larger player populations.
To receive match updates pushed into the game's back-end, a game developer must furnish OkLetsPlay with a webhook URL. Once two or more teams have confirmed a match within OkLetsPlay, the funds are escrowed and the OkLetsPlay back-end contacts the game back-end to inform it of the new match via a PUT
to the webhook URL. Should a game be aborted, due to error, the OkLetsPlay back-end will inform the game back-end of the cancellation via a DELETE
to the webhook URL. The DELETE
request is not implemented by OKLP API yet.
The webhook endpoint must accept a JSON map containing a match stub. When the incoming method is a PUT
, the game's back-end must store the match info in some persistent storage (such as a db). When the incoming method is a DELETE
, which should not happen often, the match info should be removed from the persistent storage or archived.
curl \
-X PUT \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer ${XXX-secret-jwt}' \
-d '{
"match_id": "600f369851f450dd3ecb0035",
"participants": [
{
"id": "user_id_1",
"team_id": "team_id_1"
},
{
"id": "user_id_2",
"team_id": "team_id_2"
}
],
"teams": [
{
"id": "team_id_1"
},
{
"id": "team_id_2"
}
]
}' \
${your-match-info-url}
match_id
stringThe unique id for this match.participants
arrayList of participants in the match.id
platform-idThe platform id of the player.team_id
team-idThe unique id of the player's team.teams
arrayList of teams in the match.id
team-idThe unique id for the team.If the game's back-end doesn't return a200
status, the match will be aborted.