Discord Bot Permissions & Security
The five access levels, who can configure the bot, how your API key is protected, and where the boundary sits between what Discord decides and what the GameGrid API decides.
Two gates, not one
Every command passes through two independent checks, and both must allow it.
1. The Discord gate. What access level does this member hold, through their Discord roles? You set this with /config role.
2. The API gate. Does the API key you linked with /setup carry the scope this command's endpoint needs?
They are separate systems and they fail differently. A member with Full Access running a command whose scope is missing from the key gets a scope error, not a permission error - and no amount of Discord role changes will fix it. Equally, a key with every scope grants nothing to a member the Discord gate refuses.
If a command fails, read the message. "You need at least Full Access" is the Discord gate - fix it with
/config role. Anything mentioning a scope is the API gate - fix it by creating a new key in the panel with the missing scope.
The five access levels
Levels are cumulative: each one includes everything below it.
| Level | Can run |
|---|---|
| No Access | Nothing. The default for anyone with no granted role. |
| Read Only | Status, server lists, player lists, file listings, backup lists, settings and mod listings, event and preset listings. Plus the player-side economy commands - /balance, /shop, /buy, /daily, /link, /my-transactions. |
| Console Access | Everything above, plus /console and /command. |
| Full Access | Everything above, plus start, stop, restart, backups, settings writes, mods, Windrose Plus, economy administration, chat bridge, presets and scheduled events. |
| Owner | Everything above, plus /account, /billing, /tickets and /ticket. |
`/console` requires Console Access, not Read Only, even though it only reads. Raw console output can contain RCON and admin passwords, so it sits above the ordinary read level on purpose.
/commandoutput is private to the person who ran it for the same reason.
Two things are worth knowing about how a level is worked out. A member's level is the highest level across all of their roles - so adding a low-level role never removes access granted by another. And setting a role to No Access removes its grant entirely rather than recording a zero.
Granting a level
Map a Discord role to a level with:
/config role role:@Moderators level:Console AccessA typical community ends up with something like this:
| Discord role | Level | Reasoning |
|---|---|---|
@everyone | Read Only, or nothing | Let members check whether the server is up without asking |
@Members | Read Only | Same, if you would rather not grant @everyone anything |
@Moderators | Console Access | Can run in-game commands, cannot restart or restore |
@Admins | Full Access | Can restart, restore backups, change settings |
@Owner | Owner | Billing and support tickets |
`@everyone` cannot be granted more than Read Only. The bot refuses outright. Granting
@everyoneany level at all also produces a warning, because it is easy to forget that@everyoneincludes every future member and every bot in the server.
Who can configure the bot
Configuration is not a permission level. No level - not even Owner - grants it.
| Action | Who can do it |
|---|---|
/setup, first time | The Discord server owner, or anyone with Discord's Manage Server permission |
/setup, to re-link a different key | The Discord server owner, or the person who ran `/setup` originally - nobody else |
Every /config subcommand | The same two people: the original setup user, or the Discord server owner |
/economy-setup and /economy-config | The same two people. A Full Access holder is refused |
This is deliberate. /config role decides who can restart your servers, so it cannot be something a granted level can reach - otherwise a Full Access holder could quietly promote themselves.
It also means the person who first ran /setup matters. If they leave your Discord server, the server owner can still re-run /setup and take over.
What re-running /setup does
Re-running /setup with a new key is how you rotate the bot's credentials. Verification happens before anything is stored, so a key that fails to verify leaves the working one in place - a fumbled rotation cannot take your bot offline.
But a successful re-link clears your configuration. Every role grant, every channel-to-server binding and every live console or log mirror is deleted. Your log, alert and command channels and your default server survive; the permission table does not.
This is a fail-closed measure - a new key may reach a different set of servers, so old grants are not assumed to still be appropriate. It is still a surprise if you were not expecting it, so plan for it:
1. Run /config view and screenshot it, so you have the current role table.
2. Run /config live-list and note any live mirrors.
3. Run /setup with the new key.
4. Re-apply the role grants with /config role, re-bind channels with /config channel-server, and restart mirrors with /config live-console or /config live-logs.
5. Revoke the old key in the panel.
How your API key is protected
The key you give /setup is verified against the API before it is stored, then encrypted at rest. It is never written to a log file, never shown in a command reply, and never displayed by /config view - which shows only the 8-character key id, the part that is safe to display anywhere.
The bot cannot do anything your key cannot do. If you want the bot to be able to read the console but never restart a server, create its key without servers:lifecycle - then no Discord role, no matter how it is configured, can restart anything through the bot.
Give the bot its own key, not one you also use for scripts. When you rotate or revoke it, only the bot is affected, and the audit trail tells you which integration made a call.
Two related habits: restrict the key to the specific servers your community runs, so a misconfigured /config default-server cannot reach anything else; and check GET /account/audit if you ever want to see what the bot has actually been calling.
Console output is redacted
Console and log output that the bot shows - through /console, /command and the live channel mirrors - is filtered before it is posted. Credentials and network addresses are replaced with [REDACTED].
| Redacted | Examples |
|---|---|
| Password-like values | password=, rcon_password:, admin password=, server-password: |
| Secret-like values | token=, api_key:, auth=, secret= |
| IP addresses | Both IPv4 and IPv6 |
The setting name is kept and only the value is replaced, so a line still reads rcon_password=[REDACTED] and you can see that the setting exists.
If you see
[REDACTED]where a player's IP address used to be in a join message, that is this filter working as intended, not a bug. Full unredacted output is always available in the panel console.
One deliberate gap: /preset view redacts credential-looking values but not IP addresses, because a game version number like 1.20.4.1 matches the shape of an IPv4 address and would otherwise be hidden.
Channel and visibility controls
Discord permissions still apply on top of everything above. The bot can only read and post in channels its own Discord role allows, so the ordinary way to limit who sees what is to put the bot in a private channel.
Beyond that:
- `/config command-channel` restricts
/command- and only/command- to a single channel. Other commands are unaffected, including/console. - Reply visibility is fixed per command, not configurable. Anything that could leak a credential or a private balance replies privately:
/console,/command,/balance,/buy,/daily,/link,/my-transactions,/account,/billing,/tickets,/backups restore,/settings setand every/configsubcommand. Status and lifecycle commands reply publicly so the channel can see who restarted the server. - Live mirrors post to whichever channel you point them at. Anyone who can read that channel sees the console, subject to the redaction above. Point them at a private channel.
- The log channel records who ran what. Set it with
/config log-channeland give your admins read access to it.
One inconsistency to be aware of: the
/presetand/eventcommands post their permission refusals publicly, so a member without access sees "you need at least Read Only permission" in the channel rather than privately.
Removing the bot
Two options, and they do different things.
`/config reset` clears the bot's configuration for your Discord server - the stored key, role grants, channel bindings and live mirrors - while leaving the bot in the server. Use it to start clean. It asks for confirmation first, and only the setup user or the server owner can confirm.
Removing the bot from your Discord server deletes its configuration for that server automatically.
Neither touches your API key. Revoke the key in the panel as well if you are removing the bot for good - see API Key Management.