Banco de dados
Com o banco conectado, o bot grava a aprovação da whitelist direto no MySQL do seu servidor de jogo (FiveM, MTA, SAMP…) — sem precisar aprovar duas vezes. A senha fica criptografada e nunca é exibida de volta.
1Libere o acesso externo ao MySQL
O banco do seu servidor precisa aceitar conexões de fora: libere a porta (padrão 3306) no firewall/painel da sua hospedagem e garanta que o usuário MySQL pode conectar de hosts externos (não apenas de localhost).
💡 Em muitas hospedagens de FiveM isso fica em "Firewall" ou "Portas" no painel. Se não achar, pergunte ao suporte da hospedagem: "como libero acesso externo ao MySQL?".
2Crie a conexão
Em Integrações → Banco de dados, clique em "Nova conexão" e preencha: host (IP do banco, sem http://), porta, nome do banco, usuário e senha. A "tabela padrão" é opcional — se preencher, o teste confere se ela existe.
3Teste antes de salvar
Clique em "Testar credenciais". Se aparecer sucesso, salve. Se falhar, o erro aparece na tela — veja as perguntas frequentes abaixo.
4Crie a consulta de aprovação
Na conexão salva, abra "Consultas". Em "Começar de um modelo" há consultas prontas para as bases mais comuns (vRPEX, Creative, ESX, QBCore) — escolha a do seu servidor e confira a tabela e as colunas que ela mostra antes de criar. Se preferir, escreva o SQL à mão, usando :parametros com os identificadores das perguntas da whitelist. Ex.: UPDATE vrp_users SET whitelisted = 1 WHERE id = :id
💡 Base modificada costuma trocar o nome de tabela ou coluna: o modelo só preenche o SQL, e você pode editá-lo. A execução é sempre parametrizada — o valor da resposta nunca é colado no SQL, o que impede injeção.
5Execute um teste
Dentro da consulta, use "Executar teste" preenchendo os parâmetros à mão (ex.: {"id": "1234"}) para confirmar que o SQL faz o que você espera antes de valer na aprovação real. O teste executa de verdade no seu banco — use um ID de teste.
6Vincule a consulta à whitelist
Em Whitelist, no bloco "Gravar no banco ao aprovar", escolha a conexão e a consulta e salve. A partir daí cada aprovação — manual ou automática — executa o SQL com as respostas do candidato. Se a consulta falhar ou não encontrar o registro, a candidatura não é aprovada: continua pendente, com o motivo, para a equipe corrigir e aprovar de novo. A tela avisa se a consulta pede um :parametro que nenhuma pergunta do formulário preenche.
Dúvidas comuns
Erro ECONNREFUSED — conexão recusada
O bot chegou até o servidor, mas a porta está fechada ou o MySQL não está escutando nela. Confira se a porta (3306) está liberada no firewall e se o MySQL aceita conexões externas (bind-address).
Erro ETIMEDOUT — tempo esgotado
O servidor não respondeu. Normalmente o IP/host está errado, ou o firewall da hospedagem está bloqueando silenciosamente. Revise o host e abra a porta no painel da hospedagem.
Access denied — usuário ou senha
Credenciais incorretas ou o usuário MySQL só aceita conexão local. Crie/ajuste o usuário permitindo o host remoto (ex.: CREATE USER "bot"@"%" IDENTIFIED BY "senha").
A aprovação falha: "não encontrou nenhum registro no banco"
A consulta rodou, mas não achou a linha para liberar — por isso a candidatura continua pendente, em vez de ser aprovada sem efeito no jogo. Ou o candidato informou um ID/Steam que não existe na tabela (em muitas bases o registro só é criado quando o jogador entra no servidor pela primeira vez), ou o :parametro do SQL não tem pergunta com o mesmo identificador no formulário (a whitelist avisa quando é esse o caso). Corrija a causa e aprove de novo: o candidato não precisa refazer o formulário.
A coluna não existe na tabela
O SQL usa uma coluna com nome diferente do que há no seu banco — comum em base modificada (ex.: whitelist em vez de whitelisted). Abra a consulta, troque o nome pela coluna real e execute o teste de novo.
Tabela padrão não encontrada
A conexão funcionou, mas a tabela informada não existe nesse banco. Confira o nome do banco e a grafia da tabela (ex.: vrp_users vs vrp_user).