For the complete documentation index, see llms.txt. You can also append .md to any page URL to get its markdown version.
Skip to main content
For the complete documentation index, see llms.txt.

For the complete documentation index, see llms.txt

Archive

About this feature​

Our Sign API V2 offers an embedded archive feature that allows you to securely store signed documents. This feature ensures that all documents are preserved in compliance with legal requirements.

Use cases​

  • Archiving of signed documents
  • Setting of retention periods for archived documents
Note

Integration details​

Sending a document to the archive​

To have the result from the signing session automatically sent to the archive, specify this when you create the signing session.

Add an archive object to your HTTP POST request to the Signing sessions endpoint and include sendSignatureResultsToArchive and retentionPeriod. The retentionPeriod field is required.

Note

retentionPeriod must be an ISO 8601 duration string (for example P1Y for one year).

Request example​

The following is an example of an archive object within an HTTP POST request to the Signing sessions endpoint:

{
  "archive": {
    "sendSignatureResultsToArchive": true,
    "retentionPeriod": "P1Y"
  },
  "...": "other signing session fields"
}

Archiving PKI sealing results​

Sign API v2 supports archiving sealing results for PKI signing (where the signature is cryptographically generated natively by the electronic identity scheme).

Note

This feature applies only when XADES_CONTAINER is requested through the sealTo parameter.

Requesting PKI sealing results​

To archive the generated sealing result, set sendSealingResultToArchive to true inside the archive object.

Request example​

The following is an example showing the sealTo and archive fields within an HTTP POST request to the Signing sessions endpoint:

{
  "sealTo": ["XADES_CONTAINER"],
  "archive": {
    "sendSealingResultToArchive": true,
    "retentionPeriod": "P1Y"
  }
}

Retrieving the sealing result​

When retrieving the session via an HTTP GET request to the Signing sessions endpoint, the seals output array in the response will contain the resultArchiveId which, once completed, identifies the stored sealing result.

Response example​

The following is an example showing the resultArchiveId field in the response to an HTTP GET request to the Signing sessions endpoint:

{
  "sealTo": ["XADES_CONTAINER"],
  "archive": {
    "sendSealingResultToArchive": true,
    "retentionPeriod": "P1Y"
  },
  "output": {
    "seals": [
      {
        "sealId": "01954bd0-f897-73c7-b4a8-4b989e4e44b8",
        "resultDocumentId": "f05d0dce-a7af-432b-b6b8-e455ab7c0855",
        "resultArchiveId": "f05d0dce-a7af-432b-b6b8-e455ab7c0857"
      }
    ]
  }
}

Archive confirmation and tracking​

When archiving completes, the service returns an archiveId. Receipt of an archiveId confirms that the signature result was archived successfully.

Important

You must retain the archiveId in your system. We strongly recommend storing the archiveId together with relevant signer identifiers or business references so you can trace which signer signed which document and retrieve the archived object later.

Managing archived documents​

Our Sign API v2 can send packaged results to an archive, but advanced archive operations are handled by our standalone Signicat Archive solution. See our Signicat Archive documentation for the API reference and endpoints.

You can use our Signicat Archive API for:

  • Object submission
  • Object archiving
  • Tagging of archived objects
  • Searching for archived objects
  • Retrieval of archived objects
  • Updating of archived objects
  • Object reports
  • Object audit logs via API
  • Retention management
On this page