Vote rewards
Vote rewards use the server.vote Webhook event: your handler receives the event, fetches vote data through the API, finds the player in your system, and issues the reward once.
To integrate this method, first configure the project Webhook and verify signature. Vote data is requested through GET /votes/:vote_id.
How the flow works
- Receive the Webhook event and verify signature. If is_test is
true, return204without fetching the vote and without issuing a reward. - Make sure
event_typeisserver.vote. - Take
event_id: forserver.voteit is the vote ID. - Fetch vote data through GET /votes/:vote_id and find the player in your system.
- Apply duplicate-processing protection by
event_type+event_idand issue the reward in the same transaction. - If the reward cannot be issued safely, return an error response, fix the cause, and retry delivery from the interface.
Reward example
Suppose player PlayerName voted for the server with ID 1, and your system must add 100 coins.
- GAMEMONITORING sends a Webhook with
event_type: server.voteandevent_id: 9824cabb-2203-437e-9b6c-aba43dde3e4b. - Your handler verifies signature. If the signature is invalid, it returns
401and stops. - The handler requests
GET /votes/9824cabb-2203-437e-9b6c-aba43dde3e4band receives nickname, server, and user data. - In your database, the handler finds the local account by nickname or your own account link.
- In a transaction, the handler applies duplicate-processing protection by
server.vote+event_idand adds100coins. - Handle repeated delivery of the same event by the same duplicate-processing rules.
The same flow also works for items, roles, VIP time, promo codes, or work queued in an internal system.
Vote event
When a server receives a vote, GAMEMONITORING sends the server.vote event. The event body contains only delivery data: event_type, event_id, is_test, and signature. Full vote data must be requested separately.
In this event, event_id is the vote ID. Do not use the Webhook body as the source for nickname, server, or user data: those values come from the API.
Fetch vote data
Use event_id as vote_id and request the vote data through GET /votes/:vote_id:
For reward delivery, you usually need response.nickname, response.server, and public response.user data. If the reward depends on a specific server, always check response.server.id.
Example mapping: response.nickname finds the player account in your database, response.server.id selects the reward rule for the server, and response.user.id can be stored in the reward log as the GAMEMONITORING user ID that voted.
If the API is temporarily unavailable or returns an unexpected response, do not issue a reward without verification. Return an error response, fix the cause, and retry delivery from the interface.
Complete example
The example verifies the signature, fetches vote data, prevents duplicate rewards, and applies the reward. Replace the user table name, balance field, and player lookup rule with your system structure.
Before running the example, configure the project Webhook, check GET /votes/:vote_id, and replace the SQL user update queries with your account model.