Which GLPI API should your integration use?
If your existing scripts or connectors call GLPI, you need to decide whether they stay on the legacy REST API or move to the High-level API v2. The GLPI REST API v2 authenticates only through OAuth2, using the password and authorization code grants with clients registered under Setup > OAuth Clients, while the original API remains available as the legacy API. The legacy API is the older surface that most existing GLPI scripts were written against, and v2 is the newer, OAuth2-only surface. The choice matters because it sets the authentication model for every integration you build: how clients are registered, how tokens are issued and renewed, and which credentials your automation holds.
Treat the decision as an inventory task before it becomes a coding task. List every script, connector, webhook receiver and reporting job that calls GLPI, and record which authentication method each one uses today. Scripts that depend on static API tokens or user credentials will need a different design under v2, because the v2 grants expect an OAuth client and a user or flow behind every request. Confirm with the GLPI API v2 documentation which resources and fields your integrations need before assuming they are available in v2, and check whether any of them are only reachable through the legacy API.
Plan the move in two tracks rather than one big switch. New integrations should be built on v2 where its resources cover the need, so you avoid adding legacy dependencies. Existing integrations can stay on the legacy API while you test their v2 replacements in a non-production GLPI instance, with the same data, a registered OAuth client and a documented token lifetime. Record the owner, the credential holder and the rollback path for each connector, because a token or client misconfiguration is usually the first thing that breaks during a migration.
How the two APIs differ in authentication, scope and fit
GLPI's High-level API v2 authenticates only through OAuth2. Clients obtain tokens using the password grant or the authorization code grant, and each client must be registered before it can call the API. The legacy API remains available alongside it, so the two surfaces can run in the same instance during a transition. Because the authentication model differs, a script that works on the legacy API will not simply carry over: the credential handling, token lifecycle and registration steps all change.
- v2 credentials: Every v2 call carries an OAuth2 access token, so there is no long-lived credential to embed in a script.
- Legacy credentials: The legacy API is the surface your existing scripts most likely use, and its authentication must be reviewed separately from v2.
- Grant types: v2 supports the password and authorization code grants. Choose the grant that matches whether a person or an unattended process is acting.
- Coexistence: Both surfaces can exist in one instance, so cut-over can happen one integration at a time.
- Token lifetime: Lifetime settings are configured on the OAuth client, so plan renewal before automation depends on it.
Confirm the exact grant support, token settings and credential options for your GLPI version in the GLPI API v2 documentation before you write any code.
In v2, each integration is registered as an OAuth client under Setup > OAuth Clients in the GLPI interface. The registration defines which grant the client uses and the redirect or access settings that apply to it. Registration is an administrative step, so it should be owned by a named person and recorded like any other privileged change. Legacy API access does not use this registration step, which means it is easy to lose track of which scripts hold access.
- One client per integration: Register a separate client for each connector so that access can be revoked without affecting other systems.
- Ownership: Record who requested each client, what it reads or writes and when it was last reviewed.
- Grant selection: Use the authorization code grant where a person signs in, and confirm in the documentation whether the password grant suits unattended jobs before relying on it.
- Inventory of legacy access: List every script and connector that calls the legacy API, because none of them appear in the OAuth client list.
- Change control: Treat new clients and grant changes as configuration changes that go through your normal review.
Check the registration screen in your installed version, since menu labels and options can change between releases.
Scope is where the two APIs most often differ in practice. v2 scopes control what a client may access, and they are the place to limit an integration to the data it needs. Do not assume that every endpoint or object type available through the legacy API has an equivalent in v2. Coverage has to be checked object by object against the current documentation for the version you run, and any gap decides whether the legacy API stays in use for that workflow.
- Scope granularity: Request only the scopes an integration needs, and document why each one is granted.
- Endpoint gaps: Map every endpoint your scripts call to a v2 equivalent. Any unmatched call keeps the legacy path alive.
- Write operations: Confirm which objects v2 can create, update and delete before moving automation that changes data.
- Version dependence: Coverage differs across GLPI releases, so test against the version you will run in production.
- Documentation: Confirm endpoint coverage against the GLPI API v2 documentation rather than assuming parity with the legacy API.
Before planning any migration, produce a written list of endpoints and scopes and check each one against the official documentation.
The legacy API is still the practical choice for existing tooling that already works, has no v2 equivalent for a call it makes, or belongs to a vendor integration that has not yet moved. Forcing a rewrite of stable connectors adds risk without changing what users see. Keeping the legacy path is a deliberate decision that should carry an owner, a review date and a plan for the endpoints still in use, so it does not become permanent by default.
- Connectors without a v2 path: Keep the legacy API for any integration whose required calls are not covered in v2.
- Third-party tools: Confirm with each vendor whether their connector supports v2 before you schedule a move.
- Stable scripts: Scripts that run reliably and have no open defects may stay on the legacy API until a planned change window.
- Security review: Legacy access still needs credential rotation, least-privilege accounts and logging.
- Exit criteria: Define what must be true before each legacy path is retired.
Record each remaining legacy dependency in an inventory so the retirement plan has a complete starting point.
v2 suits new integrations where OAuth2 fits your identity model and where every required call is covered by the documentation for your GLPI version. Building on v2 from the start avoids a later migration and gives each integration its own registered client with defined scopes. It also fits teams that already manage OAuth2 tokens for other platforms, since the same operational habits apply. Choose v2 only after confirming that the endpoints and write operations the build needs are present.
- Clean authentication: OAuth2 tokens and per-client registration suit automation that must be individually auditable.
- Scoped access: Narrow scopes limit the blast radius of a leaked token.
- Long-term alignment: New work on the newer surface reduces the number of paths to maintain later.
- Team skills: Teams familiar with OAuth2 flows can implement and test token handling without special tooling.
- Prototype first: Test the required calls against a non-production instance before committing the design.
Confirm endpoint coverage, grant behavior and token lifetime in the GLPI API v2 documentation before you start the build.
What you need before building on API v2
API v2 depends on a GLPI release that ships the High-level API, an OAuth client registered in the instance, and a network path that lets token requests complete over HTTPS. Work through these items before any script or connector is written, because each one blocks the next.
GLPI version that ships API v2
The High-level API is part of GLPI 11 and 12 release lines, but the exact release that first ships it is not stated in the facts available here. Check the release notes for the version you plan to run before you commit to a design. Pin that version in your test environment so your build does not drift as minor releases land. Also confirm that your PHP and database versions meet the prerequisites for that release line.
OAuth client registration
API v2 authenticates only through OAuth2, so every integration needs a client registered under Setup > OAuth Clients. Decide which grant each client uses, password or authorization code, before you register it, because the grant determines how the client obtains tokens. Record the client identifier and secret in your secrets store, not in the script. Plan who owns each client so that rotation and revocation have a named owner.
Network path and HTTPS certificate
Token requests and API calls must reach the GLPI instance over HTTPS with a certificate that clients trust. Confirm the public or internal hostname your integration will use, and check that it matches the URL GLPI is configured to serve. Test the route from every host that will run the integration, including build runners and any proxy or egress filter in between. Certificate chains issued by an internal CA need to be installed on those hosts.
Service accounts and profile rights
Each integration should act through a dedicated GLPI user rather than a personal account, so its actions can be audited and its access can be removed without affecting staff. Assign that user a profile that grants only the item types and actions the integration needs, and scope it to the entities it should see. Review the rights against the endpoints you plan to call, since a token inherits the user's permissions. Document the account owner and review date.
API documentation and legacy dependencies
Use the official RESTful API V2 documentation as the reference for endpoints, scopes and token behavior, and confirm it matches the version you are running. Inventory every existing script and connector that calls the legacy API, along with the endpoints and credentials each one uses. This inventory drives the migration plan, because the legacy API remains available while you move each integration across. Note any integration that cannot move yet.
How to register an OAuth client and migrate a first integration
This sequence moves one integration from the legacy GLPI API to the High-level API v2 without touching production first. It produces a documented inventory, a registered OAuth client for each use case, a tested token flow and a cutover with a rollback path.
Inventory existing scripts and connectors
List every script, connector and scheduled job that calls GLPI today. For each one, record the owner, the GLPI item types and actions it uses, the authentication method, the entities it reads or writes, and how often it runs. Note any dependency on legacy-only behavior, such as endpoints or fields you have not yet confirmed exist in v2. The step is done when every caller appears in one inventory with an owner and a named target GLPI instance. Confirm the v2 endpoint coverage for each item type with your GLPI version before deciding.
Decide which integrations move to v2
For each inventoried integration, decide whether it stays on the legacy API for now or moves to the High-level API v2. Integrations that need a user-delegated flow, a scope you can define narrowly, and endpoints confirmed in v2 are candidates for the move. Keep on the legacy API any integration that depends on an endpoint or behavior v2 does not cover for your version. Record the decision and the reason next to each entry. The output is a short migration list, with the first integration chosen for a pilot.
Register OAuth clients for each use case
In the GLPI interface, open Setup and then OAuth Clients, and register one client per integration rather than sharing one client across unrelated tools. Give each client a name that identifies its owner and purpose, and record the client identifier and secret in your secrets manager. Restrict the scopes to what the integration needs. The step is complete when each pilot integration has its own registered client and the secret is stored outside scripts and version control.
Choose the password or authorization code grant
Select the grant type for each use case. The password grant suits a non-interactive service account that the integration controls, so the credential lives in your secrets store and the account has the minimum profile and entity access. The authorization code grant suits flows where a person signs in and approves access. Document the choice, the account or user involved and the scopes granted. Confirm with your GLPI administrator how the chosen grant interacts with your authentication setup before going further.
Obtain and refresh tokens in a test flow
Build a small test client that requests a token with the chosen grant, calls a protected endpoint with it, and refreshes the token when it expires. Keep token lifetimes and refresh behavior as they are configured in your instance, and do not assume values from documentation alone. The check is a successful token exchange that returns an access token, followed by a successful refresh that returns a new token. Record any error responses so the production code handles them.
Run a scoped read against a non-production instance
Run the pilot integration against a non-production GLPI instance with a copy of representative data. Start with read-only calls on a single item type, then compare the returned records with the same query made through the legacy API. The step is done when the scoped read returns the expected records, respects the entity restrictions of the service account, and matches the legacy output for the fields your integration uses. Any gap found here goes back to step two as a reason to keep that integration on the legacy API.
Cut over with a rollback plan
Schedule the cutover with the integration owner and the GLPI administrator, and keep the legacy credentials and script ready to run again. Switch the pilot to the v2 client in production, watch the first scheduled runs and the GLPI logs for authentication failures, and compare a sample of written records against expectations. If results diverge or errors recur, switch the job back to the legacy path. The cutover is verified when the production job completes on v2 with matching records, and the rollback has been tested once in the non-production instance.
Mapping legacy API calls to High-level API v2 concepts
This table pairs each legacy call pattern with its High-level API v2 counterpart, the grant and client type it needs, and whether the mapping is confirmed. Treat any row marked for confirmation as open until you have checked the GLPI API v2 documentation against your own GLPI version. The main takeaway is that v2 access is OAuth2-only, so every script needs a registered client before any endpoint can be mapped.
| Legacy call pattern | High-level API v2 concept | Grant and client type | Mapping status |
|---|---|---|---|
| Session initialization | OAuth2 access token issued by the token endpoint of a registered client | Password grant for service scripts, authorization code for interactive apps | Confirm token endpoint and lifetime settings in v2 docs |
| Authentication headers | Bearer access token sent with each request | Same as the token issued to the client | Confirm exact header format in v2 docs |
| Item reads by itemtype and ID | Resource reads for each itemtype exposed by v2 | Client scopes must include the item data granted | Confirm which itemtypes v2 exposes before porting |
| Item create, update and delete | Write operations on the same resource model, governed by scopes | Authorization code preferred when actions should be attributed to a user | Confirm write support and required scopes per itemtype |
| Search criteria, fields and sorting | Query parameters defined in the v2 reference, possibly including GraphQL | Depends on scopes granted to the client | Confirm syntax and GraphQL availability; do not port search strings unchanged |
| Active entity and profile context | Per-request selection defined by v2, with rights taken from the user account | Password or authorization code, with rights inherited from the user | Confirm how entity and profile are chosen per request |
| Inventory and bulk data calls | Dedicated scope for inventory data, if present in your version | Client registered with the inventory scope | Confirm scope names and payload shape in v2 docs |
| Legacy-only functions with no listed v2 match | No confirmed equivalent yet | Keep a legacy client and legacy API access until resolved | Keep on legacy API until v2 coverage is verified |
Securing OAuth clients, tokens and service accounts
The High-level API v2 authenticates only through OAuth2, so every integration depends on a registered client, a grant type, a token and the account behind it. The cards below cover the controls that decide how much damage a leaked secret or token can do, and what to confirm in the GLPI docs for your installed version before you rely on any of them.
Client secret storage
Each OAuth client registered under Setup > OAuth Clients issues credentials that a script or connector must hold. Store the secret in a secrets manager or an encrypted vault on the integration host, never in a repository, a ticket or a shared spreadsheet. Confirm how GLPI displays and rotates a secret after creation, and plan who can regenerate it when a connector is retired.
Least-privilege profile per grant
A token acts with the rights of the GLPI user who authorized it, so the account behind each grant defines the blast radius. Create a dedicated user with a restricted profile and entity access for each integration, limited to the itemtypes and actions it needs. Review those profiles whenever the integration's scope changes.
Password grant handling
The password grant sends a user's credentials to the token endpoint in exchange for a token, so the client handles a real password. Use it only for trusted, server-side integrations, keep the service account's password in the vault, and block interactive logins for that account where your policy allows. The authorization code grant avoids sharing the password with the client and is the safer default when a person is involved.
Separate clients per integration
Register one OAuth client for each integration rather than sharing a client across scripts. A separate client lets you revoke a single connector, rotate its secret and trace its calls in the logs without disrupting others. Record the owner, purpose and grant type of every client in your configuration inventory.
Token lifetime settings
Access token lifetime and refresh behavior are set in the GLPI configuration for OAuth, and the values and defaults can differ by version. Shorten lifetimes for high-impact integrations, and confirm with your GLPI version's documentation how refresh tokens are issued, rotated and revoked. Test that an expired token fails cleanly in your connector.
TLS and API use logging
Every call that carries a token or credential must travel over TLS, including calls from internal scripts and reverse proxies that terminate connections. Forward web server and GLPI API access logs to your central log platform, and alert on token use outside expected hours, unexpected source addresses or repeated authentication failures. Confirm which log entries GLPI records for API calls in your version.
How to test v2 integrations before retiring legacy scripts
Testing a v2 integration starts with a staging GLPI instance that holds a copy of the production data model, including the entities, profiles and users that the connector will act as. Run the legacy script and its v2 replacement side by side against that instance, using the same inputs, and compare what each returns. Check that reads produce the same item sets and field values, and that writes land in the same place with the same history entries. Pay particular attention to entity and profile visibility: an OAuth2 client acts through the user who authorized it, so a read that returns complete results for a super-administrator may return fewer items for the account the connector really uses. Repeat the comparison for each account and each entity the integration touches, and record every difference before deciding anything.
Plan the rollback path for each connector separately, because the risks differ. For a read-only connector, rollback usually means keeping the legacy script installed and scheduled but disabled, so it can be re-enabled without a code change. For a connector that creates or updates items, confirm first whether the legacy API remains available in the GLPI version you run, and write down the exact steps to switch the schedule or credentials back. Keep the OAuth clients registered under Setup > OAuth Clients in place during the test period, and confirm the token lifetime settings with your GLPI administrator so that a token expiry does not look like a v2 defect. Test the rollback itself in staging, not only the forward path.
Retire a legacy script only after the team that owns the downstream process signs off on the comparison results in writing. That sign-off should name the entities and profiles covered, the write operations tested, the rollback steps and the person who will own the connector after cutover. Keep the legacy script in a read-only archive for a period agreed with the owning team, and remove it from the scheduler only once that period ends without a rollback. Confirm the current status of the legacy API against the GLPI RESTful API V2 documentation for your release before setting that period, since the decision to keep it depends on what the version you run still supports.
Why v2 calls fail after a migration
This table lists the failures teams most often hit when moving scripts and connectors from the legacy REST API to the OAuth2-only High-level API v2, with the likely cause, the check to run and the fix for each. Work through the rows in order, since a missing client registration or wrong grant type blocks every later step.
| Failure | Likely cause | Check to run | Fix |
|---|---|---|---|
| Client not found or rejected | The OAuth client was never registered under Setup > OAuth Clients, or was created in another GLPI instance | Confirm the client ID exists under Setup > OAuth Clients on the same instance the script calls | Register the client in the target instance and update the client ID in the connector configuration |
| Unsupported grant type | The integration uses a grant that v2 does not offer for its use case, often a legacy App-Token and User-Token pair carried over from v1 | Compare the grant in the script with the password or authorization code grant the v2 docs describe for the use case | Switch to the password grant for service accounts or the authorization code grant for user-driven flows, then request new tokens |
| Expired or unrefreshed token | Access tokens are short-lived and the script stores one token without a refresh step | Log the token expiry time and the HTTP status returned after the expiry point | Add a refresh routine that requests a new token before expiry and retries once on 401 responses |
| Missing scope | The token was issued without the scope that covers the endpoint, such as inventory or GraphQL | Decode or inspect the granted scopes on the token and compare them with the endpoints called | Request the required scopes when registering or requesting the token, then reissue the token |
| Profile rights too narrow | The user behind the grant has a GLPI profile without read rights on the itemtype requested, so results come back empty or forbidden | Repeat the request with the same user in the GLPI interface and check the itemtype visibility under the profile and entity | Adjust the profile rights for the service account, keeping the scope as narrow as the integration allows |
| HTTPS or certificate errors | The client does not trust the internal certificate authority, or the GLPI URL in the client config does not match the public URL | Test the endpoint with a standard TLS client from the integration host and check the certificate chain and host name | Install the internal CA in the client trust store and align the configured base URL with the certificate name |
| Legacy session assumptions | Code still calls session initialization, sends session tokens, or expects v1 response shapes after moving to v2 | Search the codebase for session init calls, legacy headers and v1 endpoint paths, then run the call against a test instance | Replace session handling with OAuth token handling and update the parsing code to the v2 response format |
Questions teams ask before moving to GLPI API v2
Will the legacy GLPI REST API still be needed after moving to API v2?
Yes, for some teams it will. GLPI's High-level API v2 is the newer interface and authenticates only through OAuth2, while the original API remains available as the legacy API. The practical question is which of your scripts and connectors depend on the legacy authentication model or endpoints. Inventory every client first, including scheduled jobs, monitoring hooks and vendor connectors that you may not own. Confirm in the GLPI API v2 documentation which functions you need are available in v2 before deciding to retire anything, and confirm the legacy API status for the exact GLPI version you run.
How long does an API v2 migration take, and what drives the duration?
No fixed duration can be stated from the supplied information, so treat any number from a vendor or partner with caution until it matches your scope. Duration is driven by the number of connectors, how many use different OAuth2 grant types (password or authorization code), the size of the data each one reads or writes, and how much testing the integrations need before cutover. Connectors that act on behalf of users usually need more design work than service accounts. Ask for a written breakdown per connector rather than one total figure.
What does the internal team need to provide for the migration?
Your team provides the knowledge and access that only you hold. That means a list of every script and connector with its owner, the GLPI itemtypes and fields each one uses, the systems that call GLPI, and the service accounts involved. You also need a test GLPI instance that matches production closely enough to validate OAuth clients, token lifetimes and permissions. Assign someone to approve OAuth client registrations under Setup > OAuth Clients and to sign off on scopes, because access decisions should stay with your security owners.
Can one internal team complete the move to API v2 alone?
Often yes, if the team already runs GLPI and has someone comfortable with OAuth2, PHP-based GLPI administration and the systems that consume the API. The work is more demanding when several teams own different connectors, when grant choices affect identity policy, or when the team lacks time to write and run regression tests. Weigh the size of your connector list against available engineering hours. A partner is most useful for the design, test plan and cutover planning, while your team keeps ownership of the business logic.
What does a fixed-scope quote for this work cover?
A fixed-scope quote covers the work listed in the written scope agreed before the engagement starts. For this topic, ask that it names each connector in scope, the target grant type and scopes for each, the testing approach, the cutover and rollback steps, and the documentation handed over. It should also state what is excluded, such as changes to the connected third-party systems or new GLPI plugins. DeployOpen does not publish a price list, and a quote follows from that written scope.
How do GLPI upgrades affect existing API clients?
Upgrades can change what your API clients depend on, so plan them as part of the migration rather than after it. Before any GLPI update, the installation documentation calls for backing up the database, the files and the config directory, including glpi.key and glpicrypt.key, and then running php bin/console db:update. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, which can affect plugin-provided endpoints your clients use. Test every connector against the target version in a staging instance and confirm the exact behavior in the release notes for that version.
Which cost drivers should we ask about before comparing offers?
Ask for the cost components separately: discovery and inventory of clients, design of OAuth client registrations and scopes, development changes per connector, test automation, cutover support and documentation. Most of the one-time cost sits in the number of connectors and how many need rework rather than simple configuration. Recurring cost appears when you keep connectors current after each GLPI release, which is worth raising when you discuss a support retainer. Request quotes that state the GLPI version assumed and the assumptions behind each connector estimate.
How DeployOpen scopes and delivers API migrations
DeployOpen starts every GLPI API migration with an inventory of what already talks to GLPI, before anyone changes a line of code. That inventory lists each script, connector, webhook receiver and monitoring job, the API version it calls, the authentication method it uses (typically a legacy session token or a user-name and password pair), the endpoints and item types it reads or writes, and the owner who can approve a change. Because the High-level API v2 authenticates only through OAuth2, every connector needs a registered client under Setup > OAuth Clients, and the inventory shows which connectors can take that change without redesign. Clients and their owners are also where the reader's own security team should look first, since each registered client is an identity that needs a named owner, a secret rotation plan and a scope review. The output is a written list the client signs off before design starts.
The scope is then written as a fixed-scope statement of work with named deliverables, acceptance criteria and a timeline agreed in writing before work begins. For this topic, that document usually covers the OAuth client design, the grant type chosen for each connector, the token lifetime settings, the migration order, the rollback path for each cutover and the verification evidence the client receives. The effort depends mainly on how many connectors exist, how many depend on the legacy API for features v2 does not yet cover, and how much of the GLPI data model they touch. Pricing follows from that written scope, and the client should ask for the components separately: discovery, client registration and testing, cutover support, and any run-time work after go-live. DeployOpen does not publish a price list, so the quote is the place to confirm which parts are one-time and which recur.
Cutover runs in stages. Each connector moves to v2 behind a test instance first, with the same read and write cases replayed against both APIs and the results compared, then moves to production one connector at a time, with the legacy path kept available until the agreed acceptance point. Verification covers token issuance and renewal, entity and profile visibility for the OAuth user, and the outcome of writes such as ticket creation. Where a connector must stay on the legacy API for now, the plan records that decision and its review date. After go-live, the client can choose an optional retainer for ongoing support, version review as GLPI releases move on, and periodic checks of the OAuth clients and their scopes. Retainers are priced against their own written terms, and the client should confirm response expectations and what is excluded before signing.
