Issuer Auto-signature

Auto-signature allows QI Tech to automatically sign, on the issuer's behalf, the documents of subsequent issuances — without a representative having to sign operation by operation.

To do so, the issuer signs an auto-signature adoption agreement only once. While this agreement is not signed, issuances keep following the regular manual signature flow.

Enablement per client

Auto-signature is not enabled by default. It is configured by QI Tech per client (tenant), including the adoption agreement template used. To enable it, contact the team suporte-dcm@qitech.com.br.

---

Prerequisites

Prerequisite	How it is met
Client enabled for auto-signature	Configured by QI Tech, with the adoption agreement template
Issuer with an approved registration	Regular issuer homologation flow
Issuer with an active signer group	Issuer signer registration

The signer group registered on the issuer is exactly who signs the adoption agreement. If it is empty or outdated at the time of approval, fix the registration before proceeding.

---

End-to-end flow

The enablement is requested by the integrator, and it is only accepted after the issuer registration is approved. There is no automatic creation: until the request is made, the issuer has no auto-signature.

1. Issuer approved. The registration goes through the regular homologation flow until the approved status. Nothing is created at this point.
2. Enablement request. The integrator calls POST /issuer_management/issuer/{issuer_key}/auto_signature. In the same call, QI Tech creates the auto-signature, generates the adoption agreement from the template configured for the client and opens the signature envelope — independently of any operation. The response already comes in the pending_signature status, with issuer_auto_signature_key and envelope_key.
3. Agreement signature. The integrator queries the signature links and directs each issuer signer to their own link. The agreement is signed outside of any operation, and can be signed before the first issuance.
4. Agreement signed. When all required signatures are completed, the auto-signature moves to enabled and the signed_at and enabled_at fields are filled in. QI Tech then issues the issuer's private certificate, used to sign the issuance documents. The signed agreement can be downloaded through the signed agreement query.
5. Refusal or expiration. If the envelope is refused, canceled or expired, the auto-signature moves to reproved and issuances follow the manual signature flow. A new enablement must be requested.

Steps 2, 4 and 5 trigger the issuer_management.auto_signature_status_change webhook — that is, the pending_signature, enabled and reproved statuses. Cancellation (canceled) does not generate a webhook and is observed by querying. Since pending_signature already comes in the request response, the webhook for this status is redundant for whoever called the endpoint — it is useful for other consumers of the same tenant.

Do not assume auto-signature is active

The request opens the envelope, but does not complete the enablement: the agreement still needs to be signed. Only consider automatic signature available for an issuance after the auto-signature is in enabled. In any other status, the document goes to manual signature — the integration must handle both paths.

---

Status machine

Status	Meaning	Signature of a new issuance
pending_term_generation	Transient state during the request	Manual
pending_signature	Agreement generated and sent for signature; signer links available	Manual
enabled	Agreement signed; issuer enabled for automatic signature	Automatic
reproved	Agreement envelope refused, canceled or expired	Manual
canceled	Auto-signature canceled	Manual

Possible transitions:

• pending_term_generation → pending_signature (both within the request) → enabled
• pending_signature → reproved (envelope refused, canceled or expired)
• pending_term_generation or pending_signature → canceled

The auto-signature is automatically canceled when the issuer leaves the approved status — that is, when it moves to reproved, expired or canceled. In this case, the enablement must be redone after the registration is approved again.

---

Endpoints

Endpoint	Purpose
POST .../auto_signature	Request the enablement for an approved issuer
GET .../auto_signature	Query the current state and the event history
GET .../auto_signature/signers	Get the signature link of each agreement signer
GET .../auto_signature/report	Download the signed adoption agreement, once the auto-signature is in enabled

How to track

There are two complementary paths:

• Webhook — issuer_management.auto_signature_status_change is sent on the pending_signature, enabled and reproved statuses. When receiving pending_signature, query the signature links.
• Query — the auto-signature query returns the current state and the full event history.

The summarized block also appears in the issuer query, in the auto_signature field:

{
    "issuer_key": "07b1ac01-5fc4-475f-930b-19595f24bc1e",
    "status": "approved",
    "auto_signature": {
        "issuer_auto_signature_key": "9c3f0f1e-6a2b-4c58-9c9c-0f6b1d2a7e34",
        "status": "enabled",
        "signed_at": "2026-02-11T14:02:31",
        "enabled_at": "2026-02-11T14:02:31"
    }
}

The field is null for issuers that never had an auto-signature requested.