Common Flow

The validation services that work by reference share the same startup: obtain the token, create an operation, and upload the assets to storage. Only then is the specific service invoked with the keys obtained.

This page brings that startup together so it doesn't have to be repeated in each service. Each step links to the page that documents its contract.

Diagram

The steps

1. Obtain the consumer token. A single token authenticates all subsequent calls and is valid for one hour. It is issued on behalf of the platform and for a specific consumer. See Authentication.

2. Create the operation. The operation groups the session assets and sets an expiration for them. It is created with POST /operation, which returns the operationId and its expiresAt. when capture starts, not before, because the expiration clock starts at that moment. See Create Operation.

3. Upload each asset. One call per capture, declaring the context that corresponds to it. Each upload returns the fileKey with which the asset is later referenced. See Save Asset, and Storage for the available contexts and the key format.

4. Invoke the validation service. The keys are sent fileKeys exactly as returned by POST /storage, with the operationId in the header operation-id. The key is not composed or interpreted: adding the context yourself leaves it duplicated and the asset does not resolve. If you need to recover the keys for an operation, they are in Get File Keys.

Which services follow this Flow

The validation services identity support the two asset modes by default, inline content and reference by key, and this Flow is the one for reference mode. The exceptions are explicit:

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

The services that are exclusively inline do not go through steps 2 and 3: the content travels in the call itself and they do not carry a header operation-id.