NexTool Solutions

O GLPI 11 tem duas APIs: a antiga, a que o próprio GLPI agora chama "API Legada", e uma nova, com OAuth2, GraphQL e documentação interativa. Testámos a nova de ponta a ponta: do token ao ticket aberto, atualizado e com acompanhamento. O primeiro tropeço surgiu antes de qualquer ticket: o GLPI entregou o token normalmente e depois recusou tudo com "The High-Level API is disabled". Este guia mostra o caminho que funcionou, com a coleção Postman testada para descarregar.

A API Legada continua a funcionar e é a que usamos no servidor MCP que liga o Claude ao GLPI. Para integrações novas, o próprio GLPI recomenda a nova.

As duas APIs do GLPI 11

Passo 1: ativar a API nova

Em Configurar > Geral > API, ative Habilitar API. Esta opção é diferente da que ativa a API Legada.

No nosso teste, com ela desativada, o pedido de token funcionou: o GLPI devolveu um token válido durante uma hora. Só na primeira chamada surgiu o erro "The High-Level API is disabled". Se o token é emitido e tudo dá 403, comece por aqui.

Passo 2: o utilizador de serviço e o cliente OAuth

1. Utilizador de serviço: uma conta só para a integração, com o perfil mínimo de que ela precisa, na entidade certa. Nunca um administrador.
2. Cliente OAuth (em Configurar > Clientes OAuth):
3. Concessões: password para sistema-a-sistema com o utilizador de serviço; authorization_code quando a aplicação age em nome de cada pessoa que inicia sessão; client_credentials é usado pelos agentes de inventário.
4. Escopos: api para a API, graphql para o GraphQL, user e email para os dados do próprio utilizador, inventory e status para fins específicos. Atribua só o que a integração usa.
5. IPs permitidos: restrinja ao servidor que vai chamar a API.

O GLPI gera o identificador e o segredo do cliente. Guarde os dois num cofre, não no código.

Passo 3: do token ao ticket

Pedir o token (válido durante 1 hora, com token de renovação):

curl -X POST https://glpi.suaempresa.com.br/api.php/token \
  -d grant_type=password -d client_id=$CLIENT_ID -d client_secret=$CLIENT_SECRET \
  -d username=$USUARIO -d password=$SENHA -d scope="api graphql"

Abrir um ticket:

curl -X POST https://glpi.suaempresa.com.br/api.php/v2.3/Assistance/Ticket \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"name": "Impressora do 2o andar sem toner", "content": "Aberto pela API v2.", "urgency": 3, "type": 1}'

O resto do caminho que testámos:

Três pormenores que apanham desprevenido

1. A opção "Habilitar API" é separada da API Legada, e o token é emitido mesmo com a API desativada. O erro só aparece depois.
2. Um escopo pedido e não permitido não dá erro no momento. Pedimos o escopo user num cliente que não o tinha: o token veio na mesma, sem esse escopo, e a rota do utilizador respondeu 403. Se uma rota dá 403 com um token válido, confira os escopos do cliente.
3. O estado vem como objeto ({"id": 1, "name": "Novo"}), não como número. Quem migra da API Legada tem de ajustar o código que lia o estado.

Quando usar cada uma

• Integração nova: API nova. O OAuth é o padrão de mercado, os recursos são mais claros e a documentação está no próprio GLPI.
• Integração que já funciona na Legada: não há pressa, mas planeie a migração. O GLPI já mostra o aviso para usar a nova.
• Aplicação que age em nome de várias pessoas (um portal, uma app): authorization_code, para que cada pessoa autorize com as próprias credenciais.
• Rotina de servidor (n8n, ERP, script): password com utilizador de serviço e IP restrito.

Descarregue a coleção testada

A coleção Postman da API do GLPI 11 tem as nove chamadas da tabela, com o token e o id do ticket guardados automaticamente de uma chamada para a outra. Preencha o endereço do seu GLPI, o cliente OAuth e o utilizador de serviço.

Teste da NexTool em 4 de outubro de 2026, num GLPI 11.0.7 de testes (API v2.3), com utilizador de serviço e cliente OAuth criados para o teste e apagados no final. As rotas e os escopos foram também conferidos no código-fonte do GLPI 11.