Qualified seal and qualified timestamp

Two things a finished document can carry that let it prove itself without us. They work on all three APIs — composition, signature and the one-call flow — and they are bought separately from the products themselves.

	What it proves	Who says so
`qeSeal`	these bytes left this organisation in this form and nobody has touched them since (eIDAS Art. 35)	us, with a qualified certificate a QTSP issued
`qualifiedTimestamp`	these exact bytes existed at this hour (eIDAS Art. 41)	an independent timestamping authority

Neither one changes the signature level. A seal is the act of a legal person and says nothing about who signed; the signature stays SES either way. See Signature levels — the distinction matters, and a document you are comparing us against probably blurs it.

Available now, to every organisation that is not a test organisation. A seal is 2 credits, a seal with its qualified timestamp 6 (the timestamp is 4 and is never sold alone). Gift credit pays for them like any other credit. An organisation that registers itself holds both by default; one opened by an operator holds them when the operator turns them on. They are asked for per call (qeSeal, qualifiedTimestamp) or by your organisation's own setting.

What they say, and what they do not. The seal is applied with DoConure's organisational certificate, not one in your organisation's name. It says the file came from DoConure and has not been altered since; it does not say who signed (that is the signature, which stays SES). With the timestamp the file is PAdES B-LT: it keeps validating after the certificate expires.

What comes back. Paid first, and what a problem leaves unused returns to the credit it came from. An envelope pays its seal and timestamp with the signature at the send; if it is cancelled, expires or is declined, they are returned (the signature is not); if they cannot be applied when the last signer finishes, they are returned at once, and so are they when the provider received the request and its answer was lost (we never repeat it). Each return is a line in your audit trail with its code (ATTESTATION_REFUNDED_*, 2130 to 2132).

It needs an external provider that has been configured for the platform, the feature enabled for your organisation, and a valid production configuration. Until all three are in place, a request that asks for one is refused with TRUST_PROVIDER_NOT_CONFIGURED or FEATURE_NOT_ENABLED, never answered with an unsealed document. A simulated provider is reported as not qualified.

Asking for one

Both are optional in settings and tri-state: true asks for it, false refuses it, and leaving the key out hands the decision to your organisation's own setting (see the table below). Sending false applies nothing and charges nothing.

POST /api/v1/compose/documents/generate
Authorization: Bearer lpdc_…

{
  "data": { "cliente": "Acme S.r.l." },
  "settings": {
    "templateId": "contract",
    "qeSeal": true,
    "qualifiedTimestamp": true
  }
}

On the signature API the same two capabilities have been called seal and timestamp since 2026-09-18, and they still are — a published field is permanent here. qeSeal and qualifiedTimestamp are accepted there too, as aliases, so one vocabulary works across all three surfaces and nothing already written breaks.

POST /api/v1/sign/envelopes

{
  "signers": { … },
  "settings": {
    "documentId": "…",
    "subject": "Service agreement",
    "qeSeal": true
  }
}

On an envelope the two are recorded as an intent and acted on when the last signer finishes, which may be days later. On a composition they are applied inside the call.

The four combinations, and what each produces

The timestamp is an option of the seal, not a product of its own: you can have the seal without it, never the other way round. A seal is a fixed annual certificate and a timestamp costs money every time, so buying origin without buying time is a position a customer is entitled to take — and the PAdES profile that results is reported back in output.compose.trust.padesProfile so nobody discovers in 2031 that they bought a seal and not ten years.

`qeSeal`	`qualifiedTimestamp`	Profile	What it is worth
false	false	`null`	an ordinary PDF
false	true	—	refused with `TIMESTAMP_REQUIRES_SEAL` (1012): the timestamp is an option of the seal and is never applied on its own — see below
true	false	`B-B`	origin, until the certificate expires — after which it cannot be validated
true	true	`B-T` or `B-LT`	origin and time. `B-LT` keeps validating after the certificate expires

What they cost. A seal applied by a qualified provider is 2 credits and its qualified timestamp 4 (6 together), paid at the send for an envelope and with the document for a composition. A seal or timestamp from a provider that is not qualified (a test or simulated one, reported with TRUST_NOT_QUALIFIED and "qualified": false) costs nothing: it attests nothing, so it is not sold. The dry run's estimatedCredits follows the same rule. What is returned when one is not applied is described at the top of this page.

Your organisation has to hold the capability

These are sold separately from the three products. An organisation that registered itself holds both from the start; for one an operator opened, we turn them on. Your administrator can see which ones are active under Settings → Trust and compliance in the console; only we can change them.

A request that asks for one you do not hold is refused:

403 Forbidden

{
  "code": "FEATURE_NOT_ENABLED",
  "number": 1007,
  "message": "Qualified electronic seal is not enabled for this organisation…",
  "details": {
    "feature": "qeSeal",
    "enabled": { "qeSeal": false, "qualifiedTimestamp": true },
    "note": "the request was refused, not downgraded"
  },
  "retryable": false
}

Refused on every API, and never quietly produced without it. That is the same reasoning as SIGNATURE_LEVEL_UNAVAILABLE: being handed a document you believe is sealed and is not is worse than being told no. Nothing is charged, and details.enabled tells you what you do hold, so an integration can adapt without a support call.

Your own settings are a separate, lower ceiling

Once a capability is active, your organisation still chooses when it applies, under Settings → Document authenticity. Three positions, and they behave the way every other gate in this API does:

	you ask `true`	you ask `false`	you say nothing
`off`	no, with a warning	no	no
`optional`	yes	no	no
`always`	yes	yes, with a warning	yes

Unlike the entitlement above, this one warns rather than refusing — you receive the ordinary document plus a SEAL_NOT_ENABLED or TIMESTAMP_NOT_ENABLED warning. The difference is that your own administrator chose this ceiling and can see it on their own settings page, so handing back less is something you can find out about and act on.

Always read the settled value, never your own request. The response echoes what actually happened:

{
  "settings": { "qeSeal": true, "qualifiedTimestamp": false, … },
  "output": {
    "compose": {
      "trust": {
        "qeSeal":             { "requested": true, "applied": true,
                                "provider": "local",
                                "appliedAt": "2026-09-23T14:02:11+00:00" },
        "qualifiedTimestamp": { "requested": true, "applied": false },
        "padesProfile": "B-B"
      }
    },
    "warnings": [ { "code": "TIMESTAMP_NOT_ENABLED", "number": 2002, … } ]
  }
}

A failure withholds the document

If you asked for a seal and it could not be applied, the composition fails — 502 with SEAL_FAILED or TIMESTAMP_FAILED — and no document comes back. Nothing is charged for the attestation.

That is deliberate. A composition can be run again, so withholding costs you a retry; handing back an unsealed PDF where a qualified seal was asked for would be claiming a property the file does not have, which is the one thing this service will not do.

Neither is marked retryable, and that is also deliberate: the provider may have performed the operation before the connection failed, and a blind retry of a paid operation is how one document costs two. Where the failure is clearly transient — the provider could not be reached at all, a rate limit, a timestamp authority that did not answer — you get TRUST_PROVIDER_UNAVAILABLE instead, which is retryable, with details.category saying why.

The line between the two is whether the provider received the request. A seal request that timed out after it was sent comes back as SEAL_FAILED with details.category: "OUTCOME_UNKNOWN" — we do not know whether it was performed, so we never repeat it on your behalf, and we record the provider's reference whenever we learned one so the operation can be reconciled afterwards.

A signature that has been given is never lost to this. An envelope behaves the opposite way on purpose: if the seal fails at completion, the envelope still completes, with SEAL_NOT_APPLIED in its warnings and padesProfile: null recorded. A person went through the whole signing flow; stranding their document because somebody else's endpoint was restarting would punish them for an outage that is not theirs, for an attestation that can be obtained again by other means.

Test organisations never buy either one

An organisation marked as scaffolding gets neither, whatever its settings say, and the response carries PAID_EXTRA_SKIPPED_ON_TEST so you can see why the profile came back null. Use the live organisation to see a sealed document.

The same goes for a single call: isTest: true together with qeSeal: true or qualifiedTimestamp: true is refused with FEATURE_NOT_AVAILABLE_IN_TEST_MODE before anything is reserved or sent to a provider.

A timestamp on its own is refused

The qualified timestamp exists only as an option of the seal. Asking for qualifiedTimestamp: true without qeSeal: true is refused with TIMESTAMP_REQUIRES_SEAL (1012, HTTP 422, not retryable), on every door — compose, flow, a batch, an envelope — before anything is rendered, reserved, sent or charged. A timestamp by itself would come from an authority that is not necessarily qualified and would read as something it is not; a sealed document without a timestamp is fine.

422 Unprocessable Entity

{
  "code": "TIMESTAMP_REQUIRES_SEAL",
  "number": 1012,
  "message": "a qualified timestamp is an option of the qualified seal and is never applied on its own: …",
  "details": { "feature": "qualifiedTimestamp", "requires": "qeSeal",
               "source": "request" },
  "retryable": false
}

details.source is request when you asked for the timestamp, and organisation setting when your organisation's own timestamp_mode is always and the document is not sealed: set Seal to always as well, or the timestamp to optional. An envelope that loses its seal before it completes finishes without either, and says so in two warnings (SEAL_NOT_APPLIED, TIMESTAMP_NOT_APPLIED).

Who performs them

A qualified seal and a qualified timestamp are DoConure capabilities. Which QTSP and which timestamping authority are behind them is ours to change — the request you write, the errors you branch on and the metadata you read back do not change when one is replaced. output.compose.trust.*.provider carries our own internal name for whoever performed it, so a support conversation has something to quote.

Where a deployment is running against a simulated authority — the whole path runs, and the token attests nothing to anybody — it says so, on every screen and in capabilities, and qualified is reported as false whatever the configuration claims.