NexTool Solutions

Documents that need signing still travel by e-mail and WhatsApp — no traceability, no known status and disconnected from the tickets that created them. The NexTool Digital Signature module, with Autentique, brings that flow inside GLPI.

Update: since October 2026 (module version 2.0), Autentique is purchased as a provider: the Digital Signature (Autentique) product already includes the module. This revision also covers the signing link over WhatsApp, bulk sending and what changed in the webhook. The comparison with DocuSeal, DocuSign and TOTVS is in Electronic signatures in GLPI: DocuSeal, Autentique, DocuSign and TOTVS.

The problem

Service agreements, acceptance terms, access authorizations, minutes and contract terminations are born from a process that is already recorded in a ticket. But the signing happens outside it: someone exports the PDF, sends it by e-mail, chases the client over WhatsApp and, days later, tries to remember where the signed version was saved. Native GLPI does store the file (Documents tab, the glpi_documents table) and links it to the ticket, but it has no notion of a signature: it does not know who has to sign, whether they signed, and it keeps no evidence trail. When someone asks “was that contract signed?”, the answer is still to dig through e-mail and hope the right attachment is still there.

Native GLPI vs Digital Signature with Autentique

It is worth separating what GLPI does on its own from what the integration adds. The GLPI core is great at attaching and versioning files, but electronic signature was never in its scope:

On validity in Brazil: Provisional Measure 2.200-2/2001 (art. 10, § 2) accepts electronic signatures without an ICP-Brasil certificate when the parties accept them as valid, and Law 14.063/2020 calls advanced the signature that uses another means of proving authorship and integrity. The qualified signature, with an ICP-Brasil certificate, is something else (see “When not to use it” below).

How it works

The Digital Signature module connects GLPI to Autentique (one of the module's four providers, alongside DocuSeal, DocuSign and TOTVS Assinatura Eletrônica) and centralizes everything in the ticket's Digital Signature tab. Starting from a document that is already attached, you prepare the submission without switching systems:

• Send straight from the ticket — the PDF that is already attached goes out for signing without copying files between systems. You can also send a company template made in Word and filled with the ticket data, the service order (with the Order Service module; see how to generate the service order as a PDF in the ticket) or a PDF uploaded on the spot.
• Multiple signers with roles — GLPI users, a whole group or outside e-mail addresses, each with their own action: Sign, Approve, Witness, Recognise or Acknowledge receipt.
• Signing order — with Require signing order switched on for the submission, each signer gets their turn in the defined sequence; switched off, everyone signs at the same time.
• Real-time tracking — each signer's status is updated by the Autentique notification, without opening its dashboard.
• Signing link over WhatsApp — each pending signer gets a button that opens WhatsApp for whoever clicked, with the message and the link ready; if the signer is a GLPI user with a mobile number on file, the chat opens already addressed to them. The send is logged in the document history.
• Signed PDF on the ticket — after the last signature, the final PDF is attached to the ticket and to every linked item, such as the computer in the handover form and the record of whoever signed.
• Additional authentication — photo of an identity document, the signer's CPF and SMS validation, depending on how critical the document is and on the Autentique account plan.
• Sandbox mode — a test environment to validate the flow without being charged.

Bulk sending with Autentique

To collect the signature of many people on the same document, such as every employee acknowledging a policy, Autentique supports the module's bulk sending: an individual document for each member of a GLPI group, with each person's name and employee ID, plus the fixed signers who sign all of them, such as HR. The documents go out through a queue and the batch panel shows sent, signed, declined and failed ones.

Bulk sending requires the webhook to be working, with a notification received in the last 30 days, and stays off until someone with permission turns it on in Settings. With the CPF requirement switched on in Autentique, it is not available.

How the module talks to Autentique

The Autentique API is GraphQL. When a document is sent, the module builds a mutation equivalent to this one, attaching the PDF and the list of signers with each one's action:

# The Autentique API is GraphQL. When a document is sent from the ticket,
# the module builds a mutation like this one (the PDF is attached to the request):
mutation CreateDocument($document: DocumentInput!, $signers: [SignerInput!]!, $file: Upload!, $sandbox: Boolean) {
  createDocument(document: $document, signers: $signers, file: $file, sandbox: $sandbox) {
    id
    name
    signatures {
      public_id
      email
      action { name }
    }
  }
}

# Variables, built from the ticket's Digital Signature tab:
# {
#   "document": { "name": "Service agreement - Ticket #1042" },
#   "signers":  [
#     { "email": "[email protected]", "action": "SIGN"    },
#     { "email": "[email protected]",  "action": "APPROVE" }
#   ],
#   "sandbox":  false
# }

The action field maps directly to the roles you choose in the tab: SIGN (Sign), APPROVE (Approve), SIGN_AS_A_WITNESS (Witness), RECOGNIZE (Recognise) and ACKNOWLEDGE_RECEIPT (Acknowledge receipt). The public_id returned for each signature is the identifier that ties the signer to the document in GLPI. One detail that cost us time: sending by e-mail does not return the signing link. When someone clicks Copy link or the WhatsApp button, the module asks Autentique for that signer's link (createLinkToSignature).

The webhook, and what we learned in support

Sending is only half the job. The piece that sustains traceability is the webhook: on every event (signed, viewed, refused), Autentique POSTs to GLPI and the ticket tab updates on its own. Running this for clients, a few details have already cost us troubleshooting time:

• The most common mistake is not in GLPI, it is in Autentique. If you forget to register the webhook URL in the Autentique dashboard, the document is sent and signed normally, but the status never comes back. Today the Integrations tab shows, below the webhook URL, the date of the last notification received and the reason for the last rejected one: after registering it, send a test document and sign it.
• The secret goes in the dashboard, not in the URL. Autentique signs every notification with HMAC in the X-Autentique-Signature header; the same secret must be in the Autentique dashboard and in the Webhook Secret field in GLPI. A secret pasted into the URL is rejected by default, because URLs end up in logs.
• Notifications arrive in bursts. When a document is completed, three notifications arrive within a few seconds. The module locks the document while processing and rereads its state before saving, so the signed PDF is attached only once.
• Document entity. The signed PDF is saved in the entity of the signature record, the same as the item the submission came from, and attached to the ticket and to the linked items.

This webhook is Autentique notifying GLPI. The native GLPI 11 webhooks work the other way round, from GLPI to other systems: see how to configure native GLPI 11 webhooks.

And before going to production, we always confirm that sandbox is off. According to the Autentique API pricing documentation, documents created in sandbox are not charged, but they are for testing only: they are deleted automatically within a few days and generate no audit record. Leaving sandbox on makes everything look fine until someone needs the document to hold up.

How to enable it

1. Purchase the Autentique provider in the customer area of the portal: the Digital Signature (Autentique) product already includes the module.
2. Install or update NexTool on your GLPI 11 or 12 and enable the Digital Signature module.
3. In the Integrations tab, Autentique section, enter the Autentique API token and the webhook secret and use Test: the response shows the account, the organization and the credits.
4. Register the webhook URL in the Autentique dashboard, with the same secret.
5. Run one document end to end in sandbox mode, switch sandbox off and go live.

Who it is for — and when not to use it

The module is meant for IT departments and operations teams that manage service agreements, system terms of use, access authorizations and any document that needs a signature with evidential value — especially those who already use Autentique and want to remove the gap between the signature and the ticket that originated it.

When not to use it:

• If you only need an on-screen signature during in-person service, with no external platform and no per-document cost, the on-screen signature of the Order Service module is a better fit.
• If the document requires a qualified signature with an ICP-Brasil certificate (A1/A3) — some regulated acts do — a signature without a certificate may not be enough; check the legal requirement first. With a paid Autentique plan, the module can also require signers to sign with an ICP-Brasil certificate.
• If your company has standardized on another provider, check whether it is one of the others the module supports (DocuSeal, DocuSign and TOTVS Assinatura Eletrônica); outside them, the module does not apply.
• If the document is not born from any GLPI record (ticket, contract, asset, supplier and others), the integration does not add the traceability that is its main value.

Compatibility

• GLPI: 11 and 12
• Plan: Licensed, through the Digital Signature (Autentique) product
• Plugin: NexTool 6.35.0 or later

Next step

Autentique is one of the providers of the Digital Signature module, part of NexTool, an ecosystem of modules that extends GLPI without custom code. Book a call for a demo in your scenario.

Sources: Autentique API documentation, pricing and sandbox, Provisional Measure 2.200-2/2001 and Law 14.063/2020. GLPI is a registered trademark of Teclib'. NexTool is not affiliated with Teclib'. Autentique is a trademark of its owner.

Reviewed by the NexTool Solutions team. The screenshots are from GLPI with the NexTool plugin, using fictitious data.