Voting, for server owners

What you get

• Free, on any claimed cluster. Claiming is free and always will be. There is no paid tier for voting and nothing about it is faster if you back the project.
• One vote per player per cluster, every 24 hours. Not one per map. A player votes once for the whole network, which is the thing most vote sites get wrong — twelve maps should not mean twelve votes.
• They can claim it on whichever map they are on. Every server in your cluster gets its own key, all of them resolve to the same cluster vote, and the reward can be handed over by whichever server they happen to log into.
• Somebody else’s server cannot claim it. A key belongs to one cluster. A vote for your cluster looked up with another cluster’s key returns 0, so a reward is never handed out twice or by the wrong network.

Votes appear on the public ranking, which is separate from search results — it counts how many people were asked to press a button, and search order is evidence and population. Nothing about voting moves a cluster in a search.

How to hook it up

Two query shapes, same behaviour. Use whichever your software already speaks — they hit the same functions, resolve the key the same way, and return the same body. Swap KEY for that server’s key from your dashboard, and NAME for your plugin’s placeholder for the player.

GET  https://www.dinodestination.com/api?object=votes&element=claim&key=KEY&username=NAME
POST https://www.dinodestination.com/api?action=post&object=votes&element=claim&key=KEY&username=NAME

GET  https://www.dinodestination.com/api/vote/status?key=KEY&username=NAME
GET  https://www.dinodestination.com/api/vote/claim?key=KEY&username=NAME

/api is the zero-redirect form. /api/ works too and answers 308 to it, preserving the method and the query.

Naming the player

eos, steamid and discordid all work in place of username on either shape. Send whichever you hold — if more than one is present the most specific wins. On ASA, eos is usually the one you have: ArkShop identifies players by EosID, and a console player has no SteamID at all.

They are separate namespaces. An EosID looked up as a username returns 0, so knowing one form of a player’s identity never claims a vote cast under another. If you send more than one, the most specific wins.

What comes back

One character, nothing else — no JSON, no newline. The status code is always 200, including when something is wrong, because a plugin parsing an integer does not read status codes and an HTML error page reads to an owner like a broken config.

status reads without changing anything. claim marks the reward as given, so call it once, after you have handed it over.

The callback, if you want one

Set a callback URL on your dashboard and we fetch it the moment somebody votes, with username and userip as query parameters. It is a convenience, not the mechanism: if it fails we record the failure and the vote still stands, and your plugin still sees a 1 from status. Nothing about the reward depends on it arriving.

How the reward reaches the player

We never touch your server. We have no RCON access, no FTP, no plugin running on your machine, and no way to give anybody anything in your game. All we do is record that somebody voted and answer 0, 1 or 2 when you ask. Handing over the reward is something your own server does.

If you run ArkShop — the usual shop plugin on ASA — the loop is three steps, and something on your side has to run them:

1. Ask us. Call status with the player’s EosID. You get back 0, 1 or 2.
2. On a 1, pay them. Send ArkShop’s command over RCON: AddPoints <EosID> <Amount>.
3. Then tell us. Call claim for that player, so the next status returns 2 and they cannot be paid twice.

A worked example

A player with EosID 0002abc… votes for your cluster. Your key for the map they are on is KEY. Rewarding them 50 shop points:

1. GET  https://www.dinodestination.com/api/vote/status?key=KEY&eos=0002abc
   ->   1                       they voted, not yet paid

2. RCON AddPoints 0002abc 50    ArkShop hands over the points

3. GET  https://www.dinodestination.com/api/vote/claim?key=KEY&eos=0002abc
   ->   1                       recorded; the next status returns 2

Step 3 is the one people skip, and skipping it means the same player collects every time your script runs. Claim after you pay, not before: if the RCON command fails you want the next run to try again, and a vote claimed before the points landed is a reward nobody received.

Something has to run those three steps

Today that is your side of it — a shop plugin that already speaks the bestservers.com shape can do it with a URL change, and otherwise it is a small script on a timer, or a bot you already run.

A self-hosted tool that does this for you is being built. It does not exist yet. When it does it will be something you run on your own machine with your own RCON details — we are not asking for them, now or then. Until it ships, the three steps above are the whole of it.

Keys

One key per server, one vote per cluster. Every server gets its own key, so platforms that require a distinct key per server are happy, and all of them resolve to the same cluster vote — a player votes once, and every key reports that one vote.

A key is a credential. If one leaks, regenerate that server’s from your dashboard: it takes effect immediately, keeps every vote you already have, and every other key keeps working. Keys live on your dashboard, behind a verified claim — claiming is free, and one claim covers the whole cluster.