Skip to main content

Upload new documents API

Documentation for uploading new documents to TS Archive.

Overview​

The TS Archive upload APIs are available for integrators to perform document integrations. The upload APIs and their technical specifications are described in the subsequent pages of this documentation.

Upload and Conservation Process Flow​

The upload flow and the related conservation process consists of the following phases:

1. Document Upload via API​

Files are uploaded through the upload APIs. The calling application must prepare the document payload according to the specifications described in the following pages.

The upload APIs are documented via Swagger. The APIs are available in both staging and production environments, and the respective links are as follows:

EnvironmentAPI Documentation
Testhttps://digital-archive-upload.test.teamsystem.digital/swagger/static/index.html#/digital-input-package/post_digital_v1_input_package
Productionhttps://digital-archive-upload.teamsystem.digital/swagger/static/index.html#/digital-input-package/post_digital_v1_input_package

Uploading new documents requires sending a multipart form-data message to the upload APIs. The upload process involves sending both the document files and, most importantly, the associated metadata. The metadata provides essential information needed to index the documents properly, ensuring they can be correctly searched and retrieved in the future.

The complete payload structure and format are described in detail in the Full Payload Meaning documentation.

For additional details, please refer to the up to date TS Archive service specification sheet.

2. PDI Identifier Response​

Upon successful upload, the API returns a unique identifier of the versioned PDI.

Important: It is the responsibility of the calling application to associate this identifier with the original uploaded document for future reference and tracking.

3. Temporary Queue Storage​

Once uploaded, the file is loaded onto Archive and resides in a temporary ingress queue. This is an intermediate stage before permanent conservation.

In production, the system optimizes the grouping of submitted documents with a logic that allows creating PdA indices that group as many documents as possible while guaranteeing conservation times. This implies that documents sent to the conservation system will remain for a certain period among the documents "to be processed".

In particular, the file group is created and documents will leave the processing queue when one of the following two conditions is met:

a) At least 1000 files of the same type, same holder, and same reference year have been received. In this case, the 1000 received files are conserved and change status.

b) A file has remained in the queue for at least 28 days. In this case, all files of that holder with the same type and reference year are grouped and a PDA is created.

For document types 2014, 2069, and 2085, the maximum queue time is 24 hours.

These two conditions ensure compliance with service SLAs and allow for a reasonable grouping mechanism.

4. Permanent Conservation​

The file is retrieved from the ingress queue and permanently stored with the creation of PDA index documents. At this point, the document enters the official conservation system.

Monitoring Document Status​

At any time after the upload, you can call the getStatus API (see the API REST Read PDI Document Status documentation) to check the current status of the PDI and monitor its progress through the conservation process.

Retention Management​

After the document has been consolidated and permanently stored, the retention date can be modified:

  • Anticipate: The retention date can be brought forward from the standard 10-year retention period
  • Extend: The retention date can be postponed up to a maximum of 30 years from the current date

This flexibility allows organizations to manage document lifecycle according to their specific legal and business requirements.