GLPI REST API: integrations with monitoring, HR, and BI tools

GLPI exposes a REST API that covers nearly every object in the system — tickets, assets, users, entities, contracts, knowledge base articles. If another system needs to read or write data into GLPI, the API is the way. This article walks through authentication, basic operations, search, and when to choose webhooks over polling.

What the API exposes

The GLPI REST API supports full CRUD across all major object types. Practical integrations:

• Monitoring → GLPI — Zabbix or Nagios detects a server outage, calls the GLPI API, creates a P1 incident with the affected asset pre-linked
• GLPI → project tools — once a change is approved in GLPI, a webhook creates a task in Jira or Trello for the implementation team
• HR system → GLPI — a new hire record automatically triggers asset assignment and access-creation tickets
• GLPI → BI tools — scheduled API calls pull ticket and asset data into Metabase or Power BI for custom dashboards

Authentication: two tokens, one session

GLPI distinguishes two token types — a distinction that confuses newcomers:

• App-Token — identifies the calling application. Created in Setup → General → API and sent in a header on every request. Optional unless the administrator restricts access by source IP or application — but it is good practice to always set it.
• User-Token — identifies the specific user whose permissions apply. Generated in the user's profile.

A call lifecycle starts with initSession, which returns a Session-Token. You then send that token in a header on every subsequent call until you call killSession:

# 1. Start a 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. Any call using the session
curl -X GET "https://glpi.example.com/apirest.php/Ticket/42" \
  -H "App-Token: <app-token>" \
  -H "Session-Token: abc123..."

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

The session token expires after a period of inactivity — long-running integrations must handle re-authentication.

CRUD: creating a ticket

Creating a ticket from a monitoring alert is the most common pattern. POST to /apirest.php/Ticket with a JSON payload:

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 unreachable",
      "content": "Monitoring alert: ping timeout since 14:32",
      "urgency": 5,
      "type": 1,
      "entities_id": 1
    }
  }'
# → {"id":12345,"message":""}

The response returns the new ticket ID, which you use for follow-ups, attachments, or asset linking in subsequent calls. Always set entities_id when creating tickets — without it the ticket lands in the root entity and may not be visible to the target helpdesk groups.

Searching: searchOptions and criteria

The most common API request is not object creation — it is searching with filters. The search endpoint uses numbered searchOptions whose IDs you can list via /apirest.php/listSearchOptions/Ticket:

# Open tickets from the last 7 days
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

The field parameter is a numeric search-option ID (for example 12 = status, 15 = date opened). The endpoint returns paginated results — the Content-Range response header and the Range: 0-49 request header control pagination. Iterate for larger result sets.

Webhooks vs polling: GLPI 11

For flows leaving GLPI outward, you used to have to poll — periodically call the API and check whether anything had changed. GLPI 11 introduced native webhooks: define a URL endpoint, pick the event type (ticket created, status changed, technician assigned), and GLPI POSTs a JSON payload to your endpoint when that event fires.

Webhooks beat polling whenever they are available — less load on the GLPI server, lower reaction latency, no dedicated cron job. For older versions (10.x), polling remains the only option; in that case use a sensible interval (5–15 minutes) and always filter by the timestamp of the last check, not the full dataset.

When to use the API vs plugins

The API is the right choice when integration is with an external system — monitoring, HR, ERP, project tools. Data flows between two separate platforms over the network.

A plugin is the right choice when you need to extend internal GLPI behaviour — new object types, custom workflows, UI changes, deep automation through hooks. Plugins run inside the GLPI process; API integrations run outside it.

Most real deployments use both. The API connects GLPI with the ecosystem. Plugins extend what GLPI does internally.