GLPI REST API: integrácie s monitoringom, HR a BI nástrojmi

GLPI má REST API, ktoré sprístupňuje takmer každý objekt v systéme — tikety, aktíva, používateľov, entity, zmluvy, články knowledge base. Ak iný systém potrebuje čítať alebo zapisovať dáta do GLPI, API je spôsob, ako to urobiť. Tento článok prejde autentifikáciu, základné operácie, vyhľadávanie a kedy zvoliť webhooks namiesto pollingu.

Čo API sprístupňuje

GLPI REST API podporuje plné CRUD operácie nad všetkými hlavnými typmi objektov. Praktické integrácie:

• Monitoring → GLPI — Zabbix alebo Nagios detekuje výpadok servera, zavolá GLPI API a vytvorí P1 incident s prepojeným aktívom
• GLPI → projektové nástroje — po schválení zmeny v GLPI webhook vytvorí úlohu v Jira alebo Trello pre implementačný tím
• HR systém → GLPI — nový zamestnanec automaticky spustí priradenie aktív a tikety na vytvorenie prístupov
• GLPI → BI nástroje — naplánované API volania sťahujú dáta o tiketoch a aktívach do Metabase alebo Power BI

Autentifikácia: dva tokeny, jedna session

GLPI rozlišuje dva typy tokenov, čo nových integrátorov často mätie:

• App-Token — identifikuje aplikáciu, ktorá API volá. Vytvorí sa v Setup → General → API a posiela sa v hlavičke každej požiadavky. Je voliteľný, pokým administrátor nezaviedol obmedzenia podľa zdrojovej IP alebo aplikácie — ale dobrá prax je vždy ho nastaviť.
• User-Token — identifikuje konkrétneho používateľa, ktorého oprávnenia sa použijú. Generuje sa v profile používateľa.

Životný cyklus volania začína initSession, ktorý vráti Session-Token. Ten potom posielate v hlavičke každého ďalšieho volania, kým neskončíte volaním killSession:

# 1. Začiatok session
curl -X GET "https://glpi.example.com/apirest.php/initSession" \
  -H "App-Token: <app-token>" \
  -H "Authorization: user_token <user-token>"
# → {"session_token":"abc123..."}

# 2. Akékoľvek volanie s touto session
curl -X GET "https://glpi.example.com/apirest.php/Ticket/42" \
  -H "App-Token: <app-token>" \
  -H "Session-Token: abc123..."

# 3. Koniec session
curl -X GET "https://glpi.example.com/apirest.php/killSession" \
  -H "App-Token: <app-token>" \
  -H "Session-Token: abc123..."

Session-Token expiruje po nečinnosti — pri dlhotrvajúcich integráciách musíte rátať s opätovným prihlásením.

CRUD: vytvorenie tiketu

Vytvorenie tiketu z monitoringu je najčastejší vzor. POST na /apirest.php/Ticket s JSON payloadom:

curl -X POST "https://glpi.example.com/apirest.php/Ticket" \
  -H "App-Token: <app-token>" \
  -H "Session-Token: <session-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "input": {
      "name": "Server SRV-05 nedostupný",
      "content": "Monitorovací alert: ping timeout od 14:32",
      "urgency": 5,
      "type": 1,
      "entities_id": 1
    }
  }'
# → {"id":12345,"message":""}

Odpoveď vráti ID nového tiketu, ktoré môžete použiť na pridanie follow-upov, priloženie súborov alebo prepojenie aktív v ďalších volaniach. Pri vytváraní tiketov vždy nastavte entities_id — bez neho sa tiket vytvorí v root entite a nemusí byť viditeľný pre cieľové helpdesk skupiny.

Vyhľadávanie: searchOptions a criteria

Najčastejšia API požiadavka nie je vytvorenie objektu, ale vyhľadávanie podľa filtra. Search endpoint používa očíslované searchOptions, ktorých zoznam získate z /apirest.php/listSearchOptions/Ticket:

# Otvorené tikety za posledných 7 dní
GET /apirest.php/search/Ticket
  ?criteria[0][field]=12
  &criteria[0][searchtype]=equals
  &criteria[0][value]=notold
  &criteria[1][link]=AND
  &criteria[1][field]=15
  &criteria[1][searchtype]=morethan
  &criteria[1][value]=2026-04-21
  &forcedisplay[0]=2
  &forcedisplay[1]=1
  &forcedisplay[2]=12

Pole field je číselné ID search option (napríklad 12 = status, 15 = dátum vytvorenia). Endpoint vracia stránkovaný výsledok — hlavička Content-Range v odpovedi a Range: 0-49 v požiadavke riadia paginatovanie. Pri väčších množinách musíte iterovať.

Webhooks vs polling: GLPI 11

Pre toky z GLPI von ste historicky museli polovať — periodicky volať API a kontrolovať, či sa niečo zmenilo. GLPI 11 priniesol natívne webhooks: definujete URL endpoint, vyberiete typ udalosti (vytvorenie tiketu, zmena stavu, priradenie technika) a GLPI pri jej výskyte pošle POST request s JSON payloadom.

Webhooks sú vždy lepšie ako polling, pokiaľ sú dostupné — menej zaťažujú GLPI server, znižujú latenciu reakcie a nepotrebujú dedikovaný cron job. Pre staršie verzie (10.x) zostáva polling jediná cesta; vtedy nastavte rozumný interval (5–15 minút) a vždy filtrujte podľa časovej značky poslednej kontroly, nie celý dataset.

Kedy API a kedy plugin

API je správna voľba, keď integrácia je s externým systémom — monitoring, HR, ERP, projektové nástroje. Dáta prúdia medzi dvoma samostatnými platformami a rozhraním je sieť.

Plugin je správna voľba, keď potrebujete rozšíriť interné správanie GLPI — nové typy objektov, vlastné workflow, úpravy rozhrania, hlboké automatizácie cez hooks. Pluginy bežia vo vnútri GLPI procesu; API integrácie bežia mimo neho.

Väčšina reálnych nasadení používa oboje. API prepája GLPI s ekosystémom. Pluginy rozširujú, čo GLPI robí interne.