NexTool Solutions

O GLPI 11 tem duas APIs: a antiga, que o próprio GLPI agora chama de "API Legada", e uma nova, com OAuth2, GraphQL e documentação interativa. Testamos a nova de ponta a ponta: do token ao chamado aberto, atualizado e com acompanhamento. O primeiro tropeço veio antes de qualquer chamado: 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 baixar.

A API Legada continua funcionando 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: ligar a API nova

Em Configurar > Geral > API, ative Habilitar API. Essa chave é diferente da que liga a API Legada.

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

Passo 2: o usuário de serviço e o cliente OAuth

1. Usuário 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 usuário de serviço; authorization_code quando a aplicação age em nome de cada pessoa que faz login; 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 usuário, inventory e status para fins específicos. Dê 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 chamado

Pedir o token (válido por 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 chamado:

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 testamos:

Três detalhes que pegam

1. A chave "Habilitar API" é separada da API Legada, e o token sai mesmo com a API desligada. O erro só aparece depois.
2. Escopo pedido e não permitido não dá erro na hora. Pedimos o escopo user num cliente que não o tinha: o token veio assim mesmo, sem esse escopo, e a rota do usuário respondeu 403. Se uma rota dá 403 com token válido, confira os escopos do cliente.
3. O status vem como objeto ({"id": 1, "name": "Novo"}), não como número. Quem migra da API Legada precisa ajustar o código que lia o status.

Quando usar cada uma

• Integração nova: API nova. 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 planeje 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, um app): authorization_code, para cada pessoa autorizar com o próprio login.
• Rotina de servidor (n8n, ERP, script): password com usuário de serviço e IP restrito.

Baixe 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 chamado guardados automaticamente entre uma chamada e outra. Preencha o endereço do seu GLPI, o cliente OAuth e o usuário de serviço.

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