Storing VeraFi API Data

The VeraFi Backend API processes a wide range of sensitive information across its verification, authentication, and document-processing workflows. Because many operations involve identification documents, facial images, liveness videos, extracted text, verification logs, and tenant-level subscription activity, it is essential for client systems to store and manage this data responsibly. Integrators are expected to apply strict security controls whenever they retain outputs from VeraFi, whether for audit purposes, workflow continuation, or analysis.

Note:
Even structured verification outputs such as OCR fields, confidence scores, extracted metadata, or verification decisions should be treated with the same level of confidentiality as the original documents.
VeraFi provides built-in mechanisms for storing uploaded or processed files, and these mechanisms rely heavily on encrypted storage. When storage is enabled for a tenant, the platform saves files under a session-specific directory following the pattern:
outputstorage/{session_id}/

Within this controlled directory, the system stores only the file types that the tenant has explicitly permitted. Depending on the tenant’s configuration, this can include identity photos, document images, or liveness videos. File categories are typically referenced through flags such as:

  • STORE_ID_AND_LICENSE_PHOTO
  • STORE_VIDEO

These flags determine whether the system should retain the uploaded assets after verification.

All files stored in this manner are encrypted using AES encryption, ensuring that even if storage is accessed outside intended workflows, no readable content is exposed. The encryption key used for securing these files is not hard-coded; instead, it is retrieved from the ConfigDBService, which manages configuration values across the platform. This design allows encryption keys to be rotated or updated without making changes to application code, and ensures that sensitive content is always protected using the most current configuration.

Restriction:
Because VeraFi encrypts stored files by default, clients must never assume direct filesystem access without the corresponding decryption logic. Any custom integration that attempts to manipulate or retrieve stored assets must rely on API-approved methods rather than bypassing the encryption layer.

In addition to encrypted files, verification logs and document-processing responses contain sensitive field-level details, extracted text, timestamps, and system decisions. These should not be logged verbatim by client systems. Logs must omit or mask sensitive content such as full document text, numerical identifiers, OTPs, user contact details, and any personally identifiable information returned through verification endpoints.

As a multi-tenant system, VeraFi also requires careful handling of tenant-specific data. Usage metrics, verification counts, subscription information, and configuration entries must be stored or referenced only within the appropriate tenant context. Systems must enforce tenant isolation not only at the API level but also within internal databases and storage layers.

Attention:
If a tenant disables file storage or opts out of storing certain uploaded media, the API will still perform the verification operation normally, but no files will be retained on disk. Integrators should not expect stored copies unless the tenant’s configuration explicitly allows it.

Whether retaining verification outputs, storing encrypted files, or maintaining subscription and usage datasets, systems integrating with VeraFi should apply secure storage practices, encryption at rest, and principled retention policies. Any retained data should support only the required operational workflows, with unnecessary attributes masked or discarded to reduce risk and maintain compliance.