Vote Rewards
Vote rewards use the server.vote and project.vote Webhook events: the handler receives the event, fetches vote data through the API, finds the user in your system, and issues the reward only once.
First configure the project Webhook and signature verification. 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.voteorproject.vote. - Use
event_idas the vote ID. - Fetch vote data through GET /votes/:vote_id and find the player in your system.
- In one transaction, apply duplicate-processing protection by
event_type+event_idand issue the reward only for a new event. - If the reward cannot be issued safely, return an error response. After fixing the cause, 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. - The handler verifies signature. If the signature is invalid, it returns
401and stops. - The handler requests
GET /votes/9824cabb-2203-437e-9b6c-aba43dde3e4b, receives nickname, server, and user data, and finds the local account. - In a transaction, the handler stores
event_type+event_idfor duplicate-processing protection. - For a new event, the handler adds
100coins in the same transaction. - On repeated delivery, the handler finds the already stored event, does not issue the reward again, and returns
204.
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 server.vote; when a project receives a vote, it sends project.vote. The event body contains only delivery data: event_type, event_id, is_test, and signature. Full vote data must be requested separately.
In either event, event_id is the vote ID. Do not use the Webhook body as the source for nickname, entity, 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, use response.entity_type and response.entity_id to distinguish the target. A server vote also contains response.server; a project vote contains response.project. Both types contain response.nickname and public response.user data.
How to use the fields: response.nickname helps find the account in your database, response.entity_type and response.entity_id select the reward rule, and response.user.id can be stored in the reward log as the GAMEMONITORING user ID that voted. Always verify that server.vote returned entity_type: server and project.vote returned entity_type: project.
If the API is temporarily unavailable or returns an unexpected response, do not issue a reward without verification. Return an error code, fix the cause, and retry delivery from the interface.
Step 3. Vote Reward Handler
The example continues the basic handler: it verifies the signature, fetches vote data, prevents duplicate processing, and applies the reward in one transaction. 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.