> For the complete documentation index, see [llms.txt](https://docs.facephi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.facephi.com/docs.facephi-en/rest-api/midapi-v2/storage.md). # Storage Storage stores the captures of a [operation](/docs.facephi-en/rest-api/midapi-v2/operations.md) 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](/docs.facephi-en/rest-api/midapi-v2/flujo-comun.md). #### 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. {% hint style="info" %} **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](#excepciones), are outside this recommendation: in them there is no other way to send the asset. {% endhint %} #### 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](/docs.facephi-en/rest-api/midapi-v2/storage/save-asset.md) in `fileKey` and the one returned by [Get File Keys](/docs.facephi-en/rest-api/midapi-v2/operations/get-file-keys.md) in each entry of `fileKeys`. {% hint style="warning" %} 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. {% endhint %} #### 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](/docs.facephi-en/rest-api/midapi-v2/document-services/form-ocr.md) | Only `FILE` | | [Voice Enrollment](/docs.facephi-en/rest-api/midapi-v2/voice-services/voice-enrollment.md) and [Voice Authentication](/docs.facephi-en/rest-api/midapi-v2/voice-services/voice-authentication.md) | Inline content only, without field `source` | | [Document Validation](/docs.facephi-en/rest-api/midapi-v2/document-services/document-validation/iniciar-validacion.md) | 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**](/docs.facephi-en/rest-api/midapi-v2/storage/save-asset.md): Stores an asset in a context of an operation and returns its key.