Archiving Service
How to securely store and preserve digital documents with our API.
A digital vault is a secure electronic repository designed to store, protect, and preserve documents over time while ensuring their integrity, traceability, and accessibility. It helps organizations meet regulatory and compliance requirements by maintaining evidence that documents have not been altered since their archival.
This functionality allows you to archive digital documents in a secure vault and retrieve them whenever needed. Stored documents are protected against unauthorized modification and benefit from long-term preservation mechanisms.
Check the getting started guide to set up your account, API key, and project before making API calls.
Archive your documents with evidential valueDocuments stored in the digital vault are securely preserved and can be retained for long periods according to your organization's retention policies. Contact us to learn more about retention periods, metadata, compliance requirements, and available archiving options.
Archive Format Recommendations
To ensure the long-term preservation, integrity, and usability of archived data, it is recommended to use open file formats that are well documented and independent of any specific vendor or proprietary technology.
Structured data should preferably use standard formats such as XML, JSON, or CSV. Documents should be converted to long-term preservation formats such as PDF/A.
The responsibility for maintaining the readability and usability of native file formats over time lies with the customer, including ensuring the availability of the software, licenses, and technical environments required to access and view such files.
Metadata Recommendations
Metadata definitions are shared across all archives within a given project. The same metadata structure and fields are consistently applied to every archived record belonging to that project.
These metadata are used to index archived content and enable efficient search and retrieval operations. Consistent metadata definitions ensure that archives can be accurately classified, filtered throughout their retention period.
Metadata associated with a deposit must comply with the following requirements:
- Format: Metadata must be provided exclusively in JSON format.
- Encoding: Metadata JSON must be encoded in UTF-8.
- Structure: Only a single-level JSON object is permitted. Nested objects, arrays, and other complex structures are not supported.
- Data Type: Metadata values must consist exclusively of string data types.
- Key Format: Metadata keys must start with a letter and only contain alphanumeric characters, dashes
-or underscores_. - Key Length: Each metadata key must not exceed 50 characters.
- Value Length: Each metadata value must not exceed 500 characters.
- Number of Metadata Entries: A deposit may contain a maximum of 50 metadata entries (50 key-value pairs).
- Total Metadata Size: The total size of the metadata JSON document, including keys, values, and JSON structure, must not exceed 60 KB.
The limits described above constitute the default service parameters.
Call the API
Request
- Path parameter:
project_key: the unique identifier of the project
- Headers:
Content-Type: multipart/form-dataX-API-KEY: YOUR_API_KEYIdempotency-Key: YOUR_UUID(optional)
- Request Body:
form-data parameter file, mandatory field, content-type "application/pdf": The file to archive.form-data parameter metadata, mandatory field, content-type: "application/json": UTF-8 encoded JSON file (max 60 KB) containing metadata. Metadata is limited to 50 entries; keys must be alphanumeric and at most 50 characters; values must be at most 500 characters.form-data parameter groupId, optional field: identifier to associate different archives (maximum 50 characters).
With Idempotency-Key
curl -X POST "https://ENVIRONMENT_URL/v3/projects/PROJECT_KEY/archive" \
-H "X-API-KEY: API_KEY" \
-H "Idempotency-Key: 7d0a8f67-9b2c-4e3d-8f1a-2b5c7e8d9f0a" \
-H "Content-Type: multipart/form-data" \
-F "file=path/to/your/file.pdf" \
-F "metadata=path/to/your/metadata.json;type=application/json" \
-F "groupId=GROUP_ID" Behavior: Retry with same key returns original response without re-processing, as described in the following table:
| Scenario | Idempotency-Key | HTTP Status | Expected Behavior |
|---|---|---|---|
| First-time request | The idempotency key has not been seen before. | 200 | The server should process the request normally and return the corresponding response. |
| Retry - Duplicate request | The same idempotency key is seen after the original request has completed. | 200 | The server must return the result of the original request (whether success or failure). |
| Missing Idempotency-Key header (V3) | The rules of the Automatic Idempotency is applied. | 200 | The rules of the Automatic Idempotency is applied. |
| Reusing key with a different payload | Same key is used with a different request body (i.e. different BLA & metadata fingerprints). | 422 | The server should respond with HTTP 422 Unprocessable Entity. |
Response
Upon successful archival, you will receive a response containing the unique archive identifier, storage timestamp, the document fingerprint and optionally document metadata. This identifier can later be used to retrieve or manage the archived document.