InovHost
Documentação de API v1

API InovHost — Controle de VPS

Controle VPS de um revendedor a partir de qualquer sistema, não só do WHMCS. Autenticação por token (chave de API), gerada pelo InovHost no painel administrativo.

Autenticação via Bearer Token Resposta em JSON Escopos granulares por ação

1 URL base

Toda chamada é um POST para essa URL, com o parâmetro action na query string:

https://cliente.inovhost.com/modules/addons/vmware/center.php
POST https://cliente.inovhost.com/modules/addons/vmware/center.php?action=vm_power_on

2 Autenticação

Envie o token no header Authorization:

Authorization: Bearer rvps_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Se por algum motivo o seu sistema não conseguir enviar headers customizados, existe um fallback: envie o token como campo do corpo do POST:

api_token=rvps_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Recomendado: use sempre o header Authorization. O fallback via corpo do POST deve ser usado apenas quando não houver alternativa.
Escopos: cada token só executa as ações para as quais foi liberado. Se o seu sistema precisa de várias funções (ex: ligar/desligar VPS e trocar senha), confirme com o InovHost que o token recebido tem todos os escopos necessários. Uma chamada com token válido, mas sem permissão para aquela ação, retorna erro (seção 6).

3 Formato de resposta

Por padrão a API responde em um formato antigo (tags soltas, mantido por compatibilidade com o WHMCS). Para integração externa, peça JSON — envie um dos dois:

  • Header Accept: application/json
  • Parâmetro ?format=json na URL (ou format=json no corpo do POST)

Exemplo de resposta JSON:

{
  "result": "success",
  "msg": "Sucesso! O comando foi executado!",
  "success": true
}

success é sempre true quando result é exatamente "success", e false em qualquer outro caso (incluindo os códigos de erro da seção 6). Trate success como a fonte da verdade — o texto de result/msg pode variar.

4 Ações disponíveis

Todas exigem ip (o IP dedicado da VPS) exceto conn e vm_create (que ainda não têm uma VPS associada). O IP pode ser enviado com ou sem porta (191.101.x.x ou 191.101.x.x:5900) — a porta é ignorada.

AçãoO que fazCampos obrigatóriosEscopo necessário
connTesta se o token é válidonenhum (qualquer chave ativa)
vm_power_onLiga a VPSipvm_power_on
vm_power_offDesliga a VPS (forçado, tipo "tirar da tomada")ipvm_power_off
vm_shut_downDesliga a VPS pelo sistema operacional (graceful)ipvm_shut_down
vm_resetReinicia a VPSipvm_reset
vm_suspendSuspende a VPSipvm_suspend
vm_unsuspendReativa uma VPS suspensaipvm_unsuspend
vm_destryEncerra o serviço (ver aviso na seção 5)ipvm_destry
vm_reinstallReinstala/formata a VPS com outro SOip, product, service_api, whmcs_url, guest_os_versionvm_reinstall
vm_changepasswordTroca a senha de um usuário dentro da VPSip, username, pwuservm_changepassword
vm_unblockallDesbloqueia a VPS (agente interno)ipvm_unblockall
vm_activatewindowsAtiva a licença do Windowsipvm_activatewindows
vm_createCria uma VPS nova (gera pedido)product, service_api, whmcs_url, billingcycle, guest_os_versionvm_create
vm_statusConsulta status/IP de uma VPS (útil para saber se um vm_create já terminou)service_apivm_status
AdminServicesTabFieldsDetalhes/status (somente leitura)ip, productAdminServicesTabFields

Campos usados em mais de uma ação

  • product — nome exato do produto tal como cadastrado no WHMCS (ex: "VPS CA 2 GB"). Peça essa lista ao InovHost.
  • service_api — um identificador que o seu sistema escolhe e controla (não é gerado por nós). Serve para rastrear qual VPS/pedido corresponde a qual registro interno seu.
  • whmcs_url — obrigatório por herança do formato antigo; pode enviar a URL do seu próprio sistema.
  • billingcycle — ciclo de cobrança do pedido (ex: monthly, quarterly, annually) — precisa ser um ciclo válido do produto no WHMCS.
  • guest_os_version — precisa bater exatamente com um valor de uma lista de sistemas operacionais que o InovHost mantém. Peça essa lista ao InovHost antes de integrar — não há endpoint público para consultá-la ainda.

4.1 Exemplos

Ligar uma VPS

# liga a VPS informada
curl -X POST "https://cliente.inovhost.com/modules/addons/vmware/center.php?action=vm_power_on&format=json" \
  -H "Authorization: Bearer rvps_SEU_TOKEN_AQUI" \
  -d "ip=191.101.20.15"

Resposta:

{ "result": "success", "msg": "Sucesso! O comando foi executado!", "success": true }

Criar uma VPS nova

curl -X POST "https://cliente.inovhost.com/modules/addons/vmware/center.php?action=vm_create&format=json" \
  -H "Authorization: Bearer rvps_SEU_TOKEN_AQUI" \
  -d "product=VPS CA 2 GB" \
  -d "service_api=meu-id-interno-123" \
  -d "whmcs_url=https://sistema-do-programador.com" \
  -d "billingcycle=monthly" \
  -d "guest_os_version=Ubuntu 20.04"

Consultar se a VPS já ficou pronta (vm_status)

A criação (vm_create) é assíncrona: o pedido é aceito na hora, mas o provisionamento real acontece depois, numa fila interna. Use o mesmo service_api enviado no vm_create para consultar o andamento — faça polling (por exemplo, a cada 15–30s) até ready vir true:

curl -X POST "https://cliente.inovhost.com/modules/addons/vmware/center.php?action=vm_status&format=json" \
  -H "Authorization: Bearer rvps_SEU_TOKEN_AQUI" \
  -d "service_api=meu-id-interno-123"

Enquanto ainda está provisionando:

{
  "result": "success",
  "domain_status": "Pending",
  "ip": "",
  "ready": "0",
  "msg": "Status consultado com sucesso!",
  "success": true
}

Quando já está pronta:

{
  "result": "success",
  "domain_status": "Active",
  "ip": "191.101.20.15",
  "ready": "1",
  "msg": "Status consultado com sucesso!",
  "success": true
}

domain_status segue os valores padrão do WHMCS (Pending, Active, Suspended, Terminated, Cancelled). Use o campo ready como sinal definitivo de "pronta para uso" — só vem "1" quando o status é Active e já existe um IP atribuído.

Se o service_api informado não existir (ou não pertencer ao seu token), a resposta é error12 — mesmo comportamento usado para negar acesso a recursos de outro revendedor, por segurança (não dá para descobrir se um service_api de outra pessoa existe ou não).

5 Avisos importantes

Leia antes de integrar.

vm_destry hoje não apaga a VPS de fato. A implementação atual desliga a VPS e marca o serviço como encerrado no WHMCS, mas a remoção efetiva do servidor virtual no hypervisor está desativada no código atual (linha comentada). Ou seja: depois de chamar essa ação, o recurso ainda existe fisicamente até alguém remover manualmente. Se isso for um problema para o fluxo do revendedor, fale com o InovHost — dá para reativar essa parte, mas é necessário confirmar antes de reabilitar uma ação destrutiva.
vm_changepassword, vm_unblockall e vm_activatewindows dependem de um agente rodando dentro da própria VPS, escutando na porta 31001. Se esse agente não estiver instalado/acessível na VPS, essas ações vão falhar silenciosamente ou dar timeout — não é um problema da API em si.
vm_create é assíncrono — a resposta imediata só confirma que o pedido foi aceito, não que a VPS já existe. Use vm_status (seção 4.1) fazendo polling com o mesmo service_api até ready vir true.

6 Erros

Resposta de erro (formato JSON):

{ "result": "error12", "msg": "Erro! Não foi possível autenticá-lo", "success": false }
CódigoSignificado
error1Token não enviado (na ação conn)
error12Token inválido/revogado, ou token válido mas sem permissão (escopo) para essa ação, ou não é o dono do serviço associado a esse IP
error201Ação não reconhecida ou ip não informado quando era obrigatório
error11, error23–error120Variam por ação — campo obrigatório faltando para aquela ação específica (o nome do campo faltante segue a ordem da tabela de campos obrigatórios da seção 4)
error130vm_status: service_api não informado
Se success vier false e o código não for autoexplicativo, entre em contato com o InovHost para confirmar o que está faltando.