Automating IT infrastructure with the GLPI API and webhooks

GLPI by itself does not run your infrastructure — it does not scan servers, patch containers, or restart services. Its strength lies elsewhere: being the hub where other tools send their signals and from which actions originate. Monitoring fires an alert, GLPI opens an incident. A change approved in GLPI kicks off a deployment pipeline. A customer ticket pushes data into your CRM. This article is about the three patterns that carry that flow: the REST API (inbound integrations), webhooks (outbound notifications), and cron-driven scheduled tasks (periodic actions).

Pattern 1: monitoring → GLPI via the REST API

The most common integration. Zabbix, Nagios, Prometheus and similar monitoring tools call the GLPI REST API when a threshold is crossed and create a ticket. A concrete example of a webhook action in Zabbix:

# Zabbix media type → custom webhook → GLPI
URL: https://glpi.example.com/apirest.php/Ticket
Headers:
  Content-Type: application/json
  App-Token: <app-token>
  Session-Token: <persistent-session>
Body:
{
  "input": {
    "name": "{HOST.NAME}: {EVENT.NAME}",
    "content": "Severity: {EVENT.SEVERITY}\\nTrigger: {TRIGGER.NAME}\\nValue: {ITEM.LASTVALUE}",
    "urgency": 5,
    "type": 1,
    "entities_id": 1,
    "itilcategories_id": 12
  }
}

For a stable flow, do not call initSession on every request — that adds needless churn. Issue a long-lived service-account session token, store it in Zabbix secrets, and refresh it once every 24 hours via a cron job on the Zabbix side.

Other systems commonly integrated this way: Grafana alerts, AlertManager, custom scripts using curl, and deployment pipelines that open an incident on failure.

Pattern 2: GLPI → external systems via webhooks

The reverse direction. As soon as something happens in GLPI (ticket created, change approved, technician assigned), GLPI can POST to an external endpoint. GLPI 11 ships native webhooks — before 11 this was handled by the FlyveMobile Webhooks plugin or by cron + a custom script.

Configuration in GLPI 11:

1. In Setup → Webhooks → Add create a webhook with the endpoint URL (for example https://hooks.slack.com/services/... or your own integration server).
2. Pick the trigger event: Ticket created, Status changed to Solved, Change approved.
3. Define the payload — JSON with placeholders for object fields: {"id": "{{id}}", "title": "{{name}}", "url": "{{url}}"}.
4. Set up authentication (HMAC signature so the receiver can verify the call really came from GLPI).

Typical scenarios:

• P1 ticket created → POST to a Slack webhook with a deep link to the ticket.
• Change approved → POST to Jenkins, which kicks off the deployment pipeline.
• "Onboarding" ticket created → POST to the HR system with a task to prepare the workstation.

Webhooks are always preferable to polling when available — less server load, lower latency, and no dedicated cron job needed on the consumer side.

Pattern 3: cron-driven scheduled tasks

For periodic actions (synchronizations, checks, maintenance) that are not reactive to an external event, use the GLPI built-in automatic actions or system cron calling the API.

Example cron script for an overnight LDAP user synchronization:

# /etc/cron.d/glpi-sync-ldap
0 2 * * * www-data php /var/www/glpi/bin/console glpi:ldap:synchronize_users \
  --ldap-filter="(memberOf=CN=GLPI-Users,OU=Groups,DC=example,DC=com)" \
  --no-interaction

For actions originating from GLPI and going outward (for example exporting inventory into a BI tool) use the GLPI cron framework via Setup → General → Automatic actions → Add custom or the GenericObject plugin with a callback hook.

Practical architecture: GLPI as a tickets bus

In a mid-sized organization GLPI typically sits at the center of this flow:

Monitoring (Zabbix/Grafana)
       │ (REST API, ticket creation)
       ▼
   ┌───────┐    Webhooks    ┌──────────┐
   │ GLPI  │ ─────────────▶ │ Slack    │
   └───┬───┘                └──────────┘
       │                    ┌──────────┐
       ├──────────────────▶ │ Jenkins  │
       │                    └──────────┘
   Cron│                    ┌──────────┐
       └──────────────────▶ │ BI tool  │
                            └──────────┘

Inbound integrations (left) arrive via the REST API. Outbound (right) leave via webhooks or cron.

Integration security

• App-Token + service-account user-token separates the integration from a human account. Rotating a person's password will not break the integration.
• HTTPS only — REST API and webhooks always over TLS. A self-signed certificate on the GLPI server is rejected by most monitoring tools.
• HMAC signature on webhooks — verifies the payload really came from GLPI and was not tampered with in transit.
• Audit log integration calls — turn on API call logging in Setup → General → API. When debugging an integration, those logs are essential.

The combination of these three patterns (REST API as input, webhooks as output, cron for scheduled actions) covers the vast majority of integration needs. More complex scenarios (with branching, conditions, retries) usually call for a dedicated integration platform — but even then GLPI stays in the middle as the source of truth for tickets and changes.