NexTool Solutions

GLPI 11 ha due API: quella vecchia, che GLPI stesso ora chiama "API legacy", e una nuova, con OAuth2, GraphQL e documentazione interattiva. Abbiamo testato la nuova da cima a fondo: dal token al ticket aperto, aggiornato e con un followup. Il primo intoppo è arrivato prima di qualsiasi ticket: GLPI ha rilasciato il token normalmente e poi ha rifiutato tutto con "The High-Level API is disabled". Questa guida mostra il percorso che ha funzionato, con la collection Postman testata da scaricare.

L'API legacy continua a funzionare ed è quella che usiamo nel server MCP che collega Claude a GLPI. Per le nuove integrazioni, GLPI stesso raccomanda quella nuova.

Le due API di GLPI 11

Passo 1: attivare la nuova API

In Configurazione > Generale > API, attivate Abilita API. Questa opzione è diversa da quella che attiva l'API legacy.

Nel nostro test, con l'opzione disattivata, la richiesta del token ha funzionato: GLPI ha restituito un token valido per un'ora. Solo alla prima chiamata è comparso l'errore "The High-Level API is disabled". Se il token viene rilasciato e tutto restituisce 403, partite da qui.

Passo 2: l'utente di servizio e il client OAuth

1. Utente di servizio: un account dedicato all'integrazione, con il profilo minimo di cui ha bisogno, nell'entità giusta. Mai un amministratore.
2. Client OAuth (in Configurazione > Client OAuth):
3. Autorizzazioni: password per il sistema-a-sistema con l'utente di servizio; authorization_code quando l'applicazione agisce per conto di ogni persona che effettua il login; client_credentials è usato dagli agenti di inventario.
4. Ambiti: api per l'API, graphql per GraphQL, user ed email per i dati dell'utente stesso, inventory e status per scopi specifici. Concedete solo ciò che l'integrazione usa.
5. IP consentiti: limitateli al server che chiamerà l'API.

GLPI genera l'identificativo e il segreto del client. Conservateli entrambi in un vault, non nel codice.

Passo 3: dal token al ticket

Richiedere il token (valido per 1 ora, con token di aggiornamento):

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"

Aprire un 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}'

Il resto del percorso che abbiamo testato:

Tre dettagli che ingannano

1. L'opzione "Abilita API" è separata dall'API legacy, e il token viene rilasciato anche con l'API disattivata. L'errore compare solo dopo.
2. Un ambito richiesto ma non consentito non dà errore subito. Abbiamo richiesto l'ambito user su un client che non lo aveva: il token è arrivato comunque, senza quell'ambito, e la rotta dell'utente ha risposto 403. Se una rotta restituisce 403 con un token valido, controllate gli ambiti del client.
3. Lo stato arriva come oggetto ({"id": 1, "name": "Novo"}), non come numero. Chi migra dall'API legacy deve adeguare il codice che leggeva lo stato.

Quando usare l'una o l'altra

• Nuova integrazione: API nuova. OAuth è lo standard di mercato, le risorse sono più chiare e la documentazione è dentro GLPI stesso.
• Integrazione che funziona già sulla legacy: non c'è fretta, ma pianificate la migrazione. GLPI mostra già l'avviso per usare quella nuova.
• Applicazione che agisce per conto di più persone (un portale, un'app): authorization_code, affinché ogni persona autorizzi con il proprio login.
• Processo lato server (n8n, ERP, script): password con utente di servizio e IP limitato.

Scaricate la collection testata

La collection Postman dell'API di GLPI 11 contiene le nove chiamate della tabella, con il token e l'id del ticket salvati automaticamente da una chiamata all'altra. Inserite l'indirizzo del vostro GLPI, il client OAuth e l'utente di servizio.

Test di NexTool del 4 ottobre 2026, su un GLPI 11.0.7 di test (API v2.3), con utente di servizio e client OAuth creati per il test ed eliminati alla fine. Le rotte e gli ambiti sono stati verificati anche nel codice sorgente di GLPI 11.