How GLPI webhooks for event-driven integrations work
A team that wants ticket and asset events in chat or automation usually starts by polling the GLPI API on a schedule, which adds load and delays. GLPI 11 webhooks are the documented outbound alternative: GLPI pushes a message to an external URL when an event happens on an item. Each webhook is triggered by an itemtype and an event, such as a ticket being created, and can carry filters so that only a subset of objects fires it. The documentation's own example alerts a Mattermost channel when a critical ticket is created, which shows the pattern most teams will copy: a narrow trigger, a filter and a single destination.
Before designing the trigger, confirm which HTTP method each receiving system expects. The GLPI webhook documentation lists POST, GET, UPDATE, PATCH and PUT as supported methods, and it strongly recommends HTTPS for the target URL. Treat the receiving endpoint as a system that accepts data from your GLPI instance, so decide early how it authenticates callers, where the URL and any tokens are stored, and who can change them. Check the GLPI webhook documentation for the exact options available in your version, since the form fields and header handling are the details most likely to differ between releases.
Webhooks are an outbound notification mechanism, not a replacement for inbound API integration. A webhook tells an external system that something changed, but it does not let that system query GLPI, update tickets, or read the full state of an asset on demand. Systems that need to create or modify records, or that must reconcile data after a missed notification, still need the REST or High-level API with proper credentials. Plan both paths together: webhooks for timely, one-way signals, and API calls for anything that writes back or repairs state.
What you need before configuring GLPI webhooks
A GLPI webhook only works when the GLPI instance, the receiving endpoint and the target system are all ready before any trigger is written. Confirm these five items with your team first, because each one changes how the webhook is built and tested.
A supported GLPI 11 instance
Confirm the GLPI version and its runtime before anything else. The installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0, and state that only MySQL and MariaDB are supported. Check the web server document root points to GLPI's public directory, because webhook calls depend on a correctly routed installation. Confirm the exact 11.x patch level you run, since webhook behavior and the database cost described later depend on it.
Database capacity for webhook history
Webhook executions can be recorded in the triggering item's history, and saved response bodies can increase database size. Before enabling logging, confirm how much room your MySQL or MariaDB instance has and who owns the growth review. Ask your DBA to plan backup size and retention for the extra rows. This is a recurring cost, not a one-time setup step.
A receiving endpoint with HTTPS
GLPI documentation strongly recommends HTTPS for webhook targets. Confirm the receiving URL, the certificate chain it presents, and whether the certificate is issued by an internal CA that GLPI's server trusts. Decide who renews the certificate and who gets alerted when it expires, since a failed TLS handshake looks like a failed webhook.
Inbound credentials on the target system
Most receiving systems require a token, shared secret or API key in a header. Create a dedicated service account or integration in the target system, not a personal user, and scope it to posting into the channels or endpoints it needs. Store the secret in a location your team controls and plan its rotation. Record which team owns the credential so it is not orphaned when someone leaves.
Agreed event types and entities
Write down which itemtypes and events will trigger webhooks, such as tickets created at critical priority, and which GLPI entities they belong to. Entity scope decides which records a webhook can see, so a webhook built for one entity should not be reused for another without review. Agree the filter logic up front, for example critical tickets only, so testing has a clear pass condition.
The target system's version and license
The receiving system, whether a chat platform, billing tool or automation engine, has its own version support window and license terms. Confirm these separately with its vendor or documentation, including whether your use case is covered by its license and which release line you will run. Do not assume GLPI's requirements tell you anything about the receiving side.
Configuring a GLPI webhook step by step
This sequence takes a GLPI event, such as a critical ticket being created, and delivers it to a chat or automation endpoint. Each step ends with a test that confirms the message arrived and the execution is recorded in the triggering item's history.
Prepare the receiving endpoint
Before touching GLPI, set up the system that will receive the event. For a chat target, create an incoming webhook in a test channel and copy its URL. Use HTTPS, which the GLPI webhook documentation strongly recommends, and confirm which HTTP method the receiving API expects. Your check is a manual test request sent from a workstation, which should return a success response and post a message to the test channel. Do not point GLPI at a production channel until this works.
Create the webhook and set its method
In GLPI, open the webhook configuration area and create a new webhook. Give it a name that identifies the target and its purpose, then enter the target URL. Choose the HTTP method from the supported options: POST, GET, UPDATE, PATCH or PUT. Chat and automation receivers usually accept POST, but confirm the method against your target's documentation. The check is that the webhook saves and appears in the webhook list with the method you selected.
Select the itemtype and event trigger
Choose the itemtype the webhook watches, such as Ticket for the critical ticket example, and the event that fires it, such as creation. Event names and available itemtypes can vary by version and installed plugins, so confirm them in your instance before you rely on them. The check is a test ticket created in a non-production entity: the webhook should fire for that event and should not fire for updates or other itemtypes you did not intend to include.
Restrict the webhook to the right entity
Set the entity scope so the webhook only considers items in the entity or entities where the notification belongs. Confirm how your version treats child entities before you decide whether to include them. This matters most in multi-entity deployments, where a webhook without scope can send one customer's tickets to another team's channel. The check is one test item in an in-scope entity that triggers the webhook and one in an out-of-scope entity that does not.
Add a filter for critical tickets
Add a filter so the webhook applies only to a subset of objects. For critical tickets only, the filter compares the ticket's priority field with the value your organization uses for critical. Confirm the exact field name and value in your GLPI version, because priority scales are configurable. The check is two test tickets: a low-priority ticket should produce no message, and a critical ticket should produce one. If both fire, the filter is not matching and needs correction before go-live.
Define the payload and headers
Write the custom payload using the item fields the receiver needs, such as the ticket title, ID, priority and a link back to the ticket. Add any required headers, such as the content type and an authorization header if the receiver needs a token. Confirm how your version stores header values and whether they are visible to other administrators, and treat tokens as secrets. The check is a test message whose title, ID and link render correctly in the target channel. A malformed payload should fail visibly in the test, not silently.
Set retries and response logging, then verify history
Configure retry behavior and decide whether response bodies are saved. Confirm the retry options in your version. Saving response bodies can affect GLPI performance and database size, so enable it only while debugging and turn it off afterward. Point the webhook at a deliberately wrong URL for one test, which should fail. The check is that the failed execution appears in the triggering item's history, and that a corrected URL then delivers the message and records the successful execution.
How triggers, filters and entity scope decide what fires
A GLPI webhook fires only when three things agree: the itemtype and event trigger match, the filter on the webhook accepts the specific object, and the object sits inside the entity scope the webhook is allowed to see. For a single ticket, the path runs roughly like this: a user or automatic action creates or updates a ticket, GLPI checks which webhooks target the ticket itemtype and that event, evaluates each webhook's filter against the saved ticket, confirms the ticket's entity falls within the webhook's scope, and only then builds the request from the payload template and headers. A failure at any step means no outbound call, and the reader should not assume a silent non-fire is a transport problem.
Multi-entity deployments need the most care. Entity scope is what stops a webhook configured for one customer or business unit from announcing tickets that belong to another, which matters when the destination is a shared chat channel or a billing system. Test each webhook with a ticket from every entity it could touch, including child entities if the webhook is meant to inherit them, and record which entity the webhook is attached to. Filters are easy to write incorrectly, for example against a field that is empty on creation but populated later, so run one create and one update test per filter. Ask your GLPI administrator or a DeployOpen engineer to confirm in the GLPI documentation for webhooks how filters handle empty values, how scope is inherited, and whether an update that fails a filter after previously passing will still send a notification.
Mapping GLPI fields to chat and automation payloads
This table shows which values a GLPI webhook can pull from the triggering item and which values the receiving chat or automation system must supply or transform. Read each row as a field you plan to map, then confirm the exact placeholder names against your GLPI 11 webhook configuration and a real test record before go-live.
| Field | Source | Receiver responsibility |
|---|---|---|
| Ticket title | GLPI ticket name, taken from the triggering item | Truncate or escape for the chat message format; confirm length limits in the receiver |
| Urgency and priority | GLPI ticket urgency and priority values, which are numeric codes in the item | Translate codes into labels such as critical or high; keep the mapping table under change control |
| Entity | Entity of the ticket, which also controls which items the webhook can see | Route to the right channel per entity; verify the entity scope is set as intended |
| Requester | Requester user linked to the ticket, usually an ID rather than a display name | Resolve the ID to a contact or channel handle; handle users with no matching account |
| Asset identifiers | Linked asset ID, name or serial fields where the ticket references an item | Look up the asset in the receiving system or CMDB; expect empty values on tickets without assets |
| Ticket URL | Built from the GLPI base URL and item ID in the payload template | Confirm the public URL matches the address users actually open, not an internal hostname |
| Event type and timestamp | Triggering event and item type supplied by the webhook configuration | Store the event for deduplication; do not assume GLPI sends each event exactly once |
| Channel, routing and severity wording | Not provided by GLPI | Receiver must supply channel IDs, tokens, on-call rules and any text that explains severity |
| Custom headers and authentication | Configured in the GLPI webhook as custom headers | Store secrets in the receiver's secret store and rotate them; prefer HTTPS endpoints |
Securing webhook endpoints, secrets and payloads
A GLPI webhook sends ticket, asset and other item data out of your instance to a URL you choose, so the receiver, the stored credentials, the payload contents and the people who configure the webhook all sit inside your security boundary. The cards below cover each of these points and what to check before a webhook goes live.
Require HTTPS for every receiver
The GLPI webhook documentation strongly recommends HTTPS, and that recommendation should be treated as a rule for any receiver that handles ticket or asset data. Reject plain HTTP targets in your review. Confirm that the receiver presents a certificate GLPI's server trusts, and that the certificate chain is kept current, because an expired certificate will silently stop deliveries that you may only notice through a missed alert.
Keep receiver tokens out of plain config
Chat, billing and automation receivers usually authenticate with a token or header value that GLPI must store to send each request. Where the webhook form allows it, avoid pasting long-lived secrets into free-text fields that many administrators can read. Ask which configuration keys hold the secret, who can read the database, and whether backups that include it are restricted to the same people who manage the platform.
Limit fields that leave GLPI
A custom payload is the main control over what data leaves the instance. Build the payload from only the fields the receiver needs, such as the ticket ID, title, priority and requester group, and leave out requester contact details, free-text descriptions and attached content unless a reviewer has agreed to them. Document the chosen fields so a later change to the template is visible during review.
Restrict webhooks to their entity
GLPI is organized into entities, and a webhook without a correct entity scope may send items from other entities to a receiver that was never meant to see them. For multi-entity instances, set the entity scope deliberately and test with an item from a second entity to confirm that it is not sent. Repeat the test whenever the entity structure or the webhook filters change.
Review who can create webhooks
A webhook is outbound data access, so anyone who can create or edit one can effectively export GLPI data. Review which profiles hold the rights to manage webhooks and keep that list short. Record who approved each receiver URL, and confirm that changes to URLs, headers and filters go through the same change process as other administrative configuration.
Plan for saved response bodies
The webhook documentation notes that saving response bodies can affect GLPI performance and database size, and a response from a chat or billing system may echo back sensitive content. Turn off response storage unless a support need requires it, set a removal routine for any stored bodies, and check whether webhook executions appear in the triggering item's history, since that history is visible to anyone who can view the item.
What saving webhook responses costs the database
The main cost of a GLPI webhook is not the outbound call but what GLPI stores about it. The GLPI webhook documentation states that saving response bodies can affect GLPI performance and database size, and that webhook executions can be written to the history of the triggering item. Every saved response adds rows to the database, and on a busy instance with a webhook on frequently changed itemtypes such as tickets, that growth compounds quickly. Decide before go-live whether response bodies are stored at all. Most teams need only the outcome of each delivery, so the default posture should be to keep status and minimal detail and drop the full body.
Treat the history entries as a second data store with its own lifecycle. Each webhook writes to the item history that users and auditors read, so a noisy integration can clutter the timeline of a ticket or asset that people rely on. Agree with the owners of the chat, billing or automation target which fields must be recorded for troubleshooting, such as the HTTP status code and the event identifier, and which payload content, possibly containing customer or personal data, must never reach the database. Confirm in your GLPI version how the history entries are recorded and whether they can be filtered, because this determines how much cleanup is manual.
Set a retention rule and monitor growth from the start. GLPI's operations guidance covers database growth, automatic actions and maintenance tasks, which is where you should look for cleanup routines that apply to your webhook data. Record a baseline of table sizes for the relevant GLPI tables, then check the trend after the first weeks of traffic and after each new webhook is enabled. Ask your GLPI partner or internal DBA to confirm the table names and growth figures in your own environment before you rely on them, since the documentation does not give sizes for a given event volume. A short review after the first month is usually enough to decide whether the logging level or the retention period needs to change.
Common webhook failures and how to fix them
This table lists the failures most often seen when GLPI webhooks are set up for event-driven integrations, with the likely cause and the fix for each. Read it as a triage guide: match the symptom you see in GLPI or the receiving system to a row, then work through the fix before changing anything else.
| Failure | Likely cause | Fix |
|---|---|---|
| Webhook never fires | Entity scope or filter does not match the object that was created or updated, for example a critical-ticket filter on a ticket in a child entity outside the webhook's scope | Check the webhook's entity scope and filter against a test object in the same entity, then relax one condition at a time until the event fires |
| Webhook fires for the wrong items | Filter set to match on an attribute that is empty or changes after creation, so the check runs against stale values | Confirm which event (create, update) and which field the filter reads, and test with a ticket created the way users actually create them |
| HTTPS certificate errors | Receiver uses a self-signed, expired or incomplete certificate chain, or the hostname does not match the certificate | Install a full certificate chain from a trusted authority on the receiver, verify the hostname, and test the endpoint from the GLPI server itself |
| Receiver rejects the payload | Custom payload template produces invalid JSON, or the receiver expects a field name, type or structure that the template does not send | Validate the rendered payload against the receiver's documented format, fix template syntax, and log a sample request on the receiver side |
| Receiver rejects headers | Missing or wrong Content-Type, authentication header or token, or a header value that GLPI does not substitute as the receiver expects | Set the headers the receiver documents, store tokens as secrets you control, and confirm the exact header names with the receiver's own administrator |
| Duplicate messages after retries | Receiver accepted the request but returned an error or timed out, so GLPI retried and the receiver processed the same event again | Make the receiver idempotent by keying on the GLPI item ID and event, return success quickly, and move slow processing to a queue |
| Database growth from logged responses | Saved response bodies accumulate in the database and webhook executions are recorded in the triggering item's history | Limit response saving to what you need, review retention, and watch database size as part of routine maintenance |
| Traffic sent over plain HTTP | Endpoint URL was entered with http, which the GLPI documentation strongly advises against | Change the endpoint to HTTPS, rotate any credentials sent over the old URL, and block plain HTTP at the receiver |
Questions buyers ask about GLPI webhook integrations
What drives the effort of a GLPI webhook integration?
The number of event types, the variety of payloads and the number of receivers drive effort most. Each webhook needs its itemtype and event trigger, a filter such as critical tickets only, a payload template, custom headers and a test against the real receiver. Entity scope adds work when several entities need different routing, because each rule must be checked against records in every entity it touches. A single chat channel fed by one ticket event is a small job. Ten event types feeding three systems with different payload formats is a fixed-scope project with its own test matrix. Ask for the event list, the receiver list and the entity model before requesting a quote.
Can one GLPI administrator configure webhooks alone?
A single administrator with the right GLPI profile can create and test simple webhooks, provided they can reach the receiver and have a safe place to test. The harder part is the receiver side: an automation platform, a chat server or a billing system needs its own endpoint, credentials and error handling. Someone who owns that system must agree to the payload contract and accept the retry behavior. Plan for two roles even when one person is doing the configuration. Confirm in your own GLPI version which profile rights cover webhook management before you assign the work.
What does the work need from our team?
Your team needs to provide four things: access to the receiving system in a test environment, a set of test records in GLPI that represent real cases, a named owner for the payload contract and a written sign-off on scope. Test records matter because a critical ticket filter can look correct and still miss tickets created through email or the API. Access to the receiver lets the team confirm headers, authentication and response codes. Sign-off protects both sides when a new event type is requested later. Ask the implementation partner to list these inputs in the written scope.
How long does testing take for a webhook project?
Testing time follows scope rather than a fixed number of days. A small set of webhooks to one receiver needs a short cycle of creating a test record, confirming the delivery and checking the logged response. Larger projects need separate passes for each event type, each entity and each filter, plus failure tests such as an unreachable receiver or a receiver returning an error. The GLPI documentation notes that saving response bodies can affect performance and database size, so tests should also confirm what gets logged. Ask for the test plan and the number of cycles as part of the fixed-scope quote.
Does GLPI log webhook responses, and what does that cost?
GLPI can record webhook executions in the history of the item that triggered them, and it can store response bodies. Both features are useful for diagnosis, but the GLPI webhook documentation warns that saving response bodies can affect performance and database size. Decide early which responses to keep, for how long and on which entities. High-volume events such as frequent ticket updates multiply the cost quickly. Your database team should review growth before enabling full response logging in production, and the decision should be written into the operations runbook.
What recurs after a webhook integration goes live?
Recurring work includes checking webhooks after each GLPI upgrade, reviewing the receiver's payload and authentication changes, watching the logged response codes and pruning history as the database grows. Each GLPI release can change how triggers or payload fields behave, so a regression test set should be kept and rerun before upgrades. Receiver changes, such as a rotated token or a new chat server version, also need a test. Ask whether support is handled through a retainer for upgrade checks and continuous testing, or through a one-time handover with documentation only.
Should webhooks use HTTPS, and how do we protect the receiver?
Use HTTPS for every webhook. The GLPI webhook documentation strongly recommends it, and it protects ticket content in transit. Beyond transport, check how the receiver authenticates incoming requests, whether custom headers carry secrets and who can view those headers in GLPI. Keep secrets out of shared payload templates where possible, and review access to the webhook configuration screens as part of the GLPI profile model. Your security team should confirm these choices against its own policy before go-live.
What should a fixed-scope quote for webhooks include?
A useful quote lists each event type, the itemtype and trigger it uses, every filter, each receiver and its payload format, the entities in scope, the failure cases to test and the logging decision. It should also state what the client provides, the test environment used, the handover documents and any recurring checks after upgrades. DeployOpen works from written scope agreed before work starts and does not publish a price list, so the quote follows from that document. Ask for the scope in writing and compare quotes against the same list of events and receivers.
How DeployOpen scopes and supports GLPI webhook integrations
DeployOpen plans, builds, tests and documents GLPI webhooks inside your own infrastructure, starting from the events your chat, billing or automation systems need. Each engagement begins with a written scope that fixes the triggers, filters, payloads and handover before any webhook is enabled.
How we scope
- Inventory the events that matter, such as critical ticket creation, mapped to GLPI itemtypes and triggers.
- Define entity scope and filters so each webhook reaches only the objects its receiving system should see.
- Record the target systems, HTTPS endpoints, methods and required headers in the written scope before work starts.
How we build
- Configure webhooks and custom payloads in a non-production GLPI instance, then test each trigger with sample events.
- Set retry behavior and response logging deliberately, weighing history visibility against database growth.
- Verify secrets, endpoint certificates and network paths between GLPI and each receiving service.
How we hand over
- Deliver a written record of every webhook, its trigger, filter, payload template, headers and owner.
- Document test cases, expected payloads and the steps to disable or change a webhook safely.
- Walk your operations team through failure symptoms, log locations and database size monitoring.
How we support
- Offer ongoing support, upgrades and testing as a retainer after handover, scoped in writing.
- Review webhook behavior when GLPI moves to a new version, since upgrades can affect triggers and payloads.
- Confirm with your team which events and receivers need changes before each retainer review cycle.
