Storage

Storage stores the captures of a operation before validating them. Each asset is stored once, is associated with a Context Context within the operation, and from that moment on it is referenced by its key in the validation services without transporting the binary again. The full journey, from the Token to the validation call, is in Common Flow.

Asset modes

Validation services receive assets in two ways, with the same request structure. The mode is declared by the field source:

Value of source	Content of the asset slots
FILE	Capture content, encoded in Base64.
FILE_KEY	Key of an already stored asset.

source is unique per request, not per asset: a request cannot combine inline content and references. When the request references any asset by key, the header operation-id is required and declares the operation to which all keys belong.

The recommended approach is reference by key. Identity validation services also support receiving the Tokenized asset in Base64 in the call itself (source: FILE), but this is not the recommended way to integrate them: the content travels in full in each validation, is not reused between calls or across services, bloats the request and brings it closer to the allowed size limit, and the capture is left without the operation that gives it traceability. Store each asset once and then reference it by its key (source: FILE_KEY).

The services that only support inline content, listed below in Exceptions, are outside this recommendation: in them there is no other way to send the asset.

Asset contexts

The Context identifies which capture is the asset and determines in which slots of which services it can be used. Each service declares, in the description of its parameters, the Context it supports in each slot.

Context	Content	Format of asset.file
TOKEN_FRONT_DOCUMENT	Front side of the Identity document, cropped.	Token of the buffer generated by the capture SDK, in Base64.
TOKEN_BACK_DOCUMENT	Back side of the Identity document, cropped.	Token of the buffer generated by the capture SDK, in Base64.
TOKEN_FACE_IMAGE	Cropped face from the Identity document.	Token of the buffer generated by the capture SDK, in Base64.
TOKEN_BEST_IMAGE	Best image from the selfie capture.	Token of the buffer generated by the capture SDK, in Base64.
TOKEN_BIN_IAD	Binary of the Injection Attack Detection capture.	Binary in Base64.

The pair (operation, context) identifies exactly one asset: a second upload of the same context in the same operation gets a response 409. If a capture already stored needs to be repeated, a new operation is created.

Key format

{operationId}/{CONTEXTO}

0192a3f4-7b21-7c44-9e1a-3f5b8c2d1e04/TOKEN_FRONT_DOCUMENT

It is the value returned by Save Asset in fileKey and the one returned by Get File Keys in each entry of fileKeys.

The key is resent exactly as received. It must not be composed or interpreted: adding the context leaves it duplicated and the asset does not resolve.

Asset usage limits

A stored asset has two usage limits:

Situation	Response
A referenced asset contains content already processed in another operation	409
An asset has exhausted the maximum number of invocations on that Endpoint	429

Storing the same capture again under another operation does not allow it to be validated again. The invocation budget is independent per operation, asset, and Endpoint; its value is agreed when the service is set up.

Exceptions

Identity validation services support both asset modes by default, inline content and key reference. These are the exceptions:

Service	Supported modes
Form OCR	Only FILE
Voice Enrollment and Voice Authentication	Inline content only, without field source
Document Validation	Reference only, without field source

In services that are exclusively inline, the content is sent in the call itself and they do not carry a header operation-id.

Available services

• Save Asset: Stores an asset in a context of an operation and returns its key.