# Truora - API reference ## Checks API **NOTE:** Truora provides a [**Postman collection online**]( https://www.postman.com/truora-api-docs/workspace/truora-api-docs/collection/26510995-ad2e7c71-b39a-40e4-8322-ae3316160634?ctx=documentation) that includes the necessary tools to simplify the testing process. Welcome to the **Truora Check** [**RESTful API**](https://en.wikipedia.org/wiki/Representational_state_transfer) reference. If you haven't already, we strongly advise you to check out our [**Guides Section**]( https://dev.truora.com/guides/index.html?product=Background%20Checks ). Truora Check API allows performing full background checks on people, vehicles and companies. There are three main types of background checks: - **Personal background check**: Verifies national IDs in multiple databases of public and legal entities in the LATAM region. For every national ID, returns information on: personal identity, criminal records, international background check, and professional background. - **Vehicle background check**: Verifies the vehicle documents and the owner identity in multiple databases of public and legal entities in the LATAM region. For every vehicle and owner type, returns information on: personal identity, driving records, criminal records, and vehicle information. - **Company background check**: Verifies the tax ID or a company name in multiple databases of public and legal entities in the LATAM region. For every company, returns the associated: business status, legal and criminal records, and media reports.

Authentication

Country	Person-National	Person-Foreigner	Company	Vehicle-National	Vehicle-Foreigner
Chile CL	national_id* date_of_birth phone_number issue_number	foreign_id* date_of_birth* phone_number first_name* last_name* native_country* issue_number	N/A	national_id* license_plate* driver_license (Santiago only)	foreign_id* first_name* last_name* date_of_birth* native_country* license_plate* driver_license (Santiago only)
Colombia CO	national_id* date_of_birth issue_date phone_number	foreign_id* or PPT* date_of_birth* phone_number issue_date*	tax_id* national_id	national_id* date_of_birth phone_number license_plate* owner_document_type owner_document_id	foreign_id* date_of_birth phone_number license_plate* issue_date*
Mexico MX	national_id* phone_number Alternative method: Use the following fields instead of national_id: first_name* last_name* state_id* gender* date_of_birth*	foreign_id*	tax_id*	license_plate* national_id vehicle_id driver_license(Estado de Mexico only)	N/A
Brazil BR	national_id* date_of_birth* region* phone_number	N/A	tax_id*	license_plate*	N/A
Costa Rica CR	national_id* phone_number	foreign_id* phone_number	N/A	license_plate*	N/A
Peru PE	national_id* date_of_birth* phone_number	foreign_id* ptp date_of_birth phone_number*	N/A	national_id* date_of_birth* license_plate*	foreign_id* ptp date_of_birth* license_plate*
International ALL	name*	name*	company_name*	N/A	N/A

(*) Required field - **POST** `` — Receive webhook Receives a webhook for the given webhook type. Body can be JSON, XML, or form-data. - **GET** `` — List checks Lists all the existing checks created in the account. If report_id is provided, it will only return the checks from the report - **GET** `` — Get check Returns the results of the check that matches the ID provided, complete with a set of scores explained below. **Scores**: - **Global Score**: Average risk associated with a person, company or vehicle, according to the background check results. The global score considers results that are validated with the ID number provided. The score ranges from 0 to 1, where 0 represents high risk and 1 low risk. - **ID Score**: Average risk associated with a person according to the background check results. The ID score considers the results that are validated with a person identity document. The score ranges from 0 to 1, where 0 represents high risk and 1 low risk. - **Name Score**: Average risk associated with a person according to the background check results. The name score considers results that are validated against the name of a person and could not be validated with their ID number. These results might have homonyms associated with them. The score ranges from 0 to 1, where 0 represents high risk and 1 low risk. In order to calculate these scores, a weighted average is considered with different weights allocated to each dataset. Scores can be customized using the config endpoints by assigning a weight to each dataset according to its relevance. Keep in mind that results from the API vary depending on the country, check type and the inputs entered on check creation. - **GET** `` — Get Check Attachments Enables the download of PDF documents associated with the check result. This will list all the files found for a given check and provide the link for downloading - **GET** `` — List Check Details Lists all details associated with a check, with support for pagination. It includes a list of data sources along with their respective information - **GET** `` — Summarize Returns a summary in a human readable way for the specified check id. It is useful when the details of the check are too long when reviewing manually - **GET** `` — Get the status of a database Retrieve the current status of all databases that match with query parameters. This endpoint assists in determining the suitability of making a Check, allowing to review the availability of a database at any given moment. - **DELETE** `` — Delete check Deletes the check that matches the Check ID provided, along with relevant information about that specific check. If the check belongs to a continuous check, it will be deleted only if isn't the first one. ### — Custom-Type The Custom Type API enables the creation of custom searches, allowing you to include only the desired datasets in background checks, thus enhancing the check efficiency. Moreover, you can customize the impact of each dataset on the global score by assigning it a weight value between 0 and 1. It's important to note that the sum of all weights must equal 1. You can use custom types in your checks to perform custom-type checks. For detailed information, refer to our [Custom Type](/guides/background_check_custom_type/) guide. - **POST** `` — Create custom type Create a custom type selecting the weight for each background check dataset and the country where it applies. Weights are numbers between 0 and 1 that represent how impactful the dataset is for the score, where datasets with weight 0 do not influence the score but are searched nonetheless. **Keep in mind that** the sum of all weights must equal 1. To perform a check with the custom type, create a Check and enter the name you gave to your custom type in ``type`` - **PUT** `` — Update custom type Allows updating a custom type. Person, vehicle, and company types are not modifiable. Please visit [How to Create a Custom Type for Background Check]( https://dev.truora.com/checks/custom_type/ ) guide for more information. - **GET** `` — List custom types Lists all custom types of the associated account. Please visit [How to Create a Custom Type for Background Check]( https://dev.truora.com/checks/custom_type/ ) guide for more information. - **DELETE** `` — Delete custom type Allows deleting a custom type. Please note that person, vehicle, and company custom types can not be deleted. After deletion, the response will display the remaining custom types associated with the country of the deleted custom type. ### — Settings Allows the configuration of parameters such as names matching type, retries and max duration. - **POST** `` — Create setting Allows setting up both retries and names matching type. Keep in mind that this feature is a configuration at a Client level, so it will affect all your check types. ### — Credentials Allows the management of credentials for the checks API. - **POST** `` — Create or update credential Creates or updates a collector credential for the specified database including username, password and authentication complements - **GET** `` — List credentials Lists all collector credentials for the associated account only including database information and available options for management - **DELETE** `` — Delete credential Deletes a collector credential for the specified database only using the database ID as a path parameter ### — Continuous Enables the creation of recurring checks with customizable frequency, providing notifications whenever there are changes in check scores. - **POST** `` — Create Continuous Check Creates a continuous check that will run background checks recurrently according to the frequency provided. - **PUT** `` — Update Continuous Checks Updates a continuous check using its ID. This method can only modify its frequency and status - **GET** `` — List Continuous Checks Lists all continuous checks created in the given account. This method returns the 'next' attribute to paginate for the next results - **GET** `` — Get Continuous Checks Returns the specified continuous check using its ID. This method returns the last check executed and provides information such as frequency, status, count and end date - **GET** `` — List Continuous Check Logs Returns Continuous Check Logs. These logs are useful for analyzing the behavior of the check over time. Each entry includes details of what changed ### — PDF Enables the export of a comprehensive PDF containing the obtained information, Truora's assigned score, and consulted datasets. For more details, refer to [Background Checks: PDF, Variables and Attachments](/guides/checks_pdf_variables_and_attachments/) guide. - **POST** `` — Create PDF Create PDF receives a check id and starts the conversion to PDF. Once the method is finished, it will return a link where the file can be downloaded - **GET** `` — Get PDF Get PDF downloads the PDF in the specified language, Spanish by default. This endpoint must be called after making the POST call ### — Batch Given a valid xlsx file, this endpoint takes the information from the file and starts creating the checks and associating it to the specified report object. For a step-by-step explanation of all methods and required fields for submitting a batch, please refer to the [Background Checks Batch via API](/guides/checks_batch_api/) guide. - **POST** `` — Create Batch This endpoint facilitates the creation of batches of different types. This endpoint does not include input file uploading or batch start logic. The check inputs to be uploaded in the file can be manually mapped using ``columns_mapping.{input_name}`` body params, by default the inputs accepted by the check type will be mapped. The request will return a ``columns`` array with the order in which the inputs should be in the xlsx file. The batch creation request returns a temporary URL in the ``file_upload_link`` field. This URL must be used to make a *PUT* request with the file containing the mapped batch data. **It is crucial to note that the URL has a limited expiration time (30min) and will only allow the first submitted file to be uploaded. Therefore, it is highly recommended to carefully review the information before uploading.** - **POST** `` — Request Batch Report Generation This endpoint requests the generation of a report for a specific batch. The format of the report can be specified via a query param. - **POST** `` — Start Batch This endpoint starts the execution of a specific batch. The batch needs to have an uploaded file for this to succeed. - **PUT** `` — Stop Batch This endpoint is used to stop a specific batch (updating its status to "stopped") only if it's currently in progress or not started yet. - **GET** `` — Get Batch This endpoint returns a specific batch's information, including its creation date, size, status and failure reason. - **GET** `` — Get Batch Report This endpoint obtains a previously requested batch report. If no report exists yet for the batch it returns a 404 response. ## Shared Accounts Truora Shared accounts API allows accessing services that are transversal to all other services like **Background checks** or **Validators**

Authentication

To access Truora's services and perform API calls securely, you need to authenticate your requests. This is done by including a specific authentication token, known as the **”Truora-API-Key”** in the header of your requests. By providing this key in your API requests, you establish a secure and authorized connection, enabling seamless interaction with Truora's services. - If you haven't already, sign up for a free account [here](https://account.truora.com/#/auth/login) before generating your Truora-API-Key. - Learn how to generate your **Truora-API-Key** [here](https://dev.truora.com/guides/authentication/). **Base URL:** `https://api.identity.truora.com` ### — Web Digital Identity Web is a versatile platform that allows you to create a customized process to authenticate your users. It allows you to use a number of validators in a unique process to simplify user identity verification. Here you will find the endpoints you need to create process links and get results. If you need to create process flows please see the [Documentation](/digital-identity/). - **POST** `` — Send Identity Process Link Allows to generate and send identity process access link for complete validations in assisted flow. - **POST** `` — Generate Token Once the flow has been created and published, a POST request must be made to generate a temporary API Key. This should be generated every time a user validation is performed. - **GET** `` — Download Process PDF Retrieves the PDF document for a specified process by its ID. If the PDF has not been requested before, it is generated first, progressing through: - 202 Accepted → `"file_status"`: `"requested"` - 202 Accepted → `"file_status"`: `"in_progress"` - 302 Found * → Redirects to the PDF file when ready - 200 OK → Returns the file If the PDF has already been generated, the response immediately returns: - 302 Found * → Redirects to the PDF file when ready - 200 OK → Returns the file Polling: If the file is not ready (`202 Accepted`), retry until `302 Found` or `200 OK`. * 302 Redirect Handling: Most API clients and browsers follow redirects automatically. However, if your API client does not, extract the Location header containing the PDF's URL and make a GET request to download the file. - **GET** `` — Get Result Allows you to retrieve the current status and details of a process. The ``status`` begins as ``pending`` and updates to either ``success`` or ``failure`` when the process completes. - Pending: The process is still ongoing. - Success: All steps in the process have been successfully completed. If the flow includes validators, all ``validation_status`` values must also be successful. - Failure: Occurs due to an internal error, timeout, or if the process is declined or expired. Here's a comprehensive list of reasons why a process or validation might be declined or expired, as recorded in the ``declined_reason`` and ``expired_reason`` fields: - Declined Reasons - Expired Reasons If a process includes validators and the identity process times out because a validation did not complete, but all inputs have been uploaded, the system grants an additional 5 minutes to receive a validation response with the final status. This behavior occurs up to 3 times. On the final attempt to retrieve the validation response, if the validation remains in the ``pending`` status, the identity process status will update to ``failure``, with ``failure_status`` set to ``expired``. If a process includes the attributes ``override_status`` and ``override_status_history``, it means the final status was modified by an authorized user. In this case, use the ``override_status`` attribute instead of ``status`` to determine the final status of the process. The ``override_status_history`` attribute will contain the history of changes made to the status. - **GET** `` — Download Process Video Call Recordings Retrieves the video call recordings for a specified process by its ID. If the video call recordings have not been requested before, it is generated first, progressing through: - 202 Accepted → `"file_status"`: `"requested"` - 202 Accepted → `"file_status"`: `"in_progress"` - 302 Found * → Redirects to the video call recordings file when ready - 200 OK → Returns the file If the video call recordings have already been generated, the response immediately returns: - 302 Found * → Redirects to the video call recordings file when ready - 200 OK → Returns the file Polling: If the file is not ready (`202 Accepted`), retry until `302 Found` or `200 OK`. * 302 Redirect Handling: Most API clients and browsers follow redirects automatically. However, if your API client does not, extract the Location header containing the video call recordings's URL and make a GET request to download the file. ### — Web Integration Integrate Truora products with applications. ### — WhatsApp Manage WhatsApp Business lines, inbound flows, campaigns, and sessions. - **POST** `` — Create Inbound Flows Set up inbound message that triggers a specific flow. All inputs are required for inbound creation. To finish the inbound creation process, you must access the following link, by adding the **PhoneNumber** and the **activating message**. when you need to put a space in the activation message write this code %20 https://api.whatsapp.com/send/?phone=PhoneNumber&text=activatingmessage Example https://api.whatsapp.com/send/?phone=57317770000&text=Hola%20Truora - **POST** `` — Create WABA subscription This endpoint allows users to create a WhatsApp Business Account (WABA) subscription. Users can initiate and configure the subscription process by providing the necessary information to establish a connection or subscription with a WABA, facilitating communication and interaction with WhatsApp users. - **POST** `` — Provider Statuses This endpoint receives and processes the status of a WhatsApp message from a WhatsApp provider. It enables system to handle and manage the status information associated with WhatsApp messages, facilitating effective monitoring and processing of message delivery and engagement. - **POST** `` — Cancell Campaign This endpoint offers the capability to cancel an active campaign. Users can initiate the cancellation process for a specific campaign, preventing further message deliveries and interactions. It provides a means to swiftly and effectively halt campaign activities when necessary. - **POST** `` — Finish WhatsApp session Finishes an ongoing WhatsApp session for the given waba_phone_number and phone_number. The user is notified by WhatsApp that the session has ended. Optional body fields: reason (closure reason), closed_by (override; defaults to authenticated user from authorizer). - **POST** `` — Update Inbound Flow Allows updating an inbound flow. Note: Do not forget that if you already have a whatsapp link created and you update it, you must generate a new link. - **PUT** `` — Put WABA Line config This endpoint provides the functionality to configure and customize the details of a WhatsApp Business Account (WABA) line. Users can modify various parameters and preferences to tailor the configuration of their WABA line according to their specific needs and preferences. - **GET** `` — Get WABA Line This endpoint provides the functionality to retrieve detailed information about a WhatsApp Business Account (WABA) line. Users can access essential data related to the WABA line's configuration, contact information, messaging capabilities, and integration options, facilitating effective management and utilization of the WABA line. - **GET** `` — Get Inbound Flow This endpoint allows users to retrieve information about a previously created inbound. Users can access details and data related to a specific inbound. - **GET** `` — List Inbound Flows This endpoint allows users to retrieve a list of created inbound flows. Users can access information about each inbound flow. - **GET** `` — List WABA Lines This endpoint retrieves a list of WhatsApp Business (WABA) lines that have been assigned to a Truora account. It provides essential information about each WABA line, including line details, configuration settings, and associated data, allowing account holders to manage and monitor their WhatsApp Business lines efficiently. - **GET** `` — Get Result Allows you to retrieve the current status and details of a process. The ``status`` begins as ``pending`` and updates to either ``success`` or ``failure`` when the process completes. - Pending: The process is still ongoing. - Success: All steps in the process have been successfully completed. If the flow includes validators, all ``validation_status`` values must also be successful. - Failure: Occurs due to an internal error, timeout, or if the process is declined or expired. Here's a comprehensive list of reasons why a process or validation might be declined or expired, as recorded in the ``declined_reason`` and ``expired_reason`` fields: - Declined Reasons - Expired Reasons If a process includes validators and the identity process times out because a validation did not complete, but all inputs have been uploaded, the system grants an additional 5 minutes to receive a validation response with the final status. This behavior occurs up to 3 times. On the final attempt to retrieve the validation response, if the validation remains in the ``pending`` status, the identity process status will update to ``failure``, with ``failure_status`` set to ``expired``. If a process includes the attributes ``override_status`` and ``override_status_history``, it means the final status was modified by an authorized user. In this case, use the ``override_status`` attribute instead of ``status`` to determine the final status of the process. The ``override_status_history`` attribute will contain the history of changes made to the status. - **GET** `` — Get Campaign This endpoint provides the functionality to retrieve detailed information about a specific campaign. Users can access comprehensive data related to the campaign. - **GET** `` — Get Process Validations This API endpoint allows you to retrieve the current state and information of the process validations. - **GET** `` — List WABAs This endpoint retrieves a list of WhatsApp Business Accounts that have been assigned to a Truora account. - **DELETE** `` — Remove Inbound Flow This endpoint allows users to remove inbound flows. Users can initiate the removal process for specific inbound flows, effectively eliminating them from the system. It provides a means to manage and clean up inbound flows when they are no longer needed or relevant. - **PATCH** `` — Update WABA Line This endpoint allows users to update the configuration of a WhatsApp Business Account (WABA) line both in the Truora platform and in meta. ### — WA Engagement Increase your customer engagement by automating your customer service, marketing and sales process in WhatsApp. - **POST** `` — Delete Agent Templates This endpoint allows the deletion of agent message templates. Agent can specify the template names in the request body. The endpoint checks if template names are provided; if not, it returns an appropriate error message. - **POST** `` — Update agent capacity settings This endpoint allows toggling agent capacity functionality for an account and updating both default and user-specific capacity settings. For the latter update type, multiple capacities can be updated in a single request. - **POST** `` — Send Outbound Message Sends an Outbound Message as a first interaction to an user. The Outbound Message ``status`` needs to be ``APPROVED`` before it can be sent. - **POST** `` — Update agent status This endpoint allows the update of an agent's status. The options are either online or offline. - **POST** `` — Create Outbound Messages Creates an Outbound Message that allows sending messages to users as a first interaction. Each outbound message has two dynamic evaluations assigned by Meta: a status and a quality rating. Both are subject to change over time based on review processes and user feedback. Status values: - `PENDING`: The outbound is under review by Meta and cannot be sent yet. - `APPROVED`: The outbound has been approved and is eligible to be sent. - `REJECTED`: The outbound was rejected by Meta and cannot be used. - `FLAGGED`: The outbound has received a low quality rating. This is a warning state. If the quality improves to HIGH or MEDIUM for 7 consecutive days, the status will revert to APPROVED. - `DISABLED`: The outbound maintained a low quality rating for over 7 days and was disabled. It cannot be edited or used to send messages. - `PAUSED`: The outbound has been temporarily paused and cannot be sent. Quality rating values: - `HIGH`: High read rate with no negative feedback (e.g., spam reports or blocks). - `MEDIUM`: Some negative signals such as low engagement, spam reports, or occasional blocks. - `LOW`: Frequent user reports, blocks, or very low engagement; the template may be paused. - `PENDING`: Default value when the template is created. There is not enough data yet to evaluate quality. - **POST** `` — Create Agent Template This endpoint allows the creation of new agent message templates. Users can specify the name, type and content of the message template. The endpoint ensures that each message template name is unique for the account. If an attempt is made to create a message template with a name that already exists, or if the client's message template limit is reached, appropriate error messages are returned. - **POST** `` — Request a new chat export This endpoint allows creating a new chat export request. After succeeding, the corresponding export process will start executing asynchronously. An email will be sent to the requester once it finishes. - **POST** `` — Force chat assignment dequeue This endpoint gives users the option of overriding an enqueued chat assignment request and assign the chat immediately - **POST** `` — Send a message to a chat The send endpoint is designed to send a message to a chat specified by the chat id, the message is sent via the channel associated with the chat. - **PUT** `` — Update Outbound Message Updates an Outbound Message that allows to send messages to users as a first interaction. Outbound messages need to be approved before they can be used. - **PUT** `` — Update Agent Template This endpoint allows the update of an agent message template. Agent can specify the new content text of the message template. The endpoint checks if the new content text is valid; if not, it returns an appropriate error message. - **PUT** `` — Update chat owner/status This endpoint is in charge of updating a specific chat's owner and/or status. If the chat does not exist, an error message is returned. - **PUT** `` — Update chat tags This endpoint allows the user to update the tags of a specific chat. If the tags are not valid, the endpoint returns an appropriate error response. - **GET** `` — Download Process PDF Retrieves the PDF document for a specified process by its ID. If the PDF has not been requested before, it is generated first, progressing through: - 202 Accepted → `"file_status"`: `"requested"` - 202 Accepted → `"file_status"`: `"in_progress"` - 302 Found * → Redirects to the PDF file when ready - 200 OK → Returns the file If the PDF has already been generated, the response immediately returns: - 302 Found * → Redirects to the PDF file when ready - 200 OK → Returns the file Polling: If the file is not ready (`202 Accepted`), retry until `302 Found` or `200 OK`. * 302 Redirect Handling: Most API clients and browsers follow redirects automatically. However, if your API client does not, extract the Location header containing the PDF's URL and make a GET request to download the file. - **GET** `` — Search Chats This endpoint retrieves information for multiple chats, with optional filters to refine the search. It provides a high-level overview of chat metadata and attributes, excluding actual messages. - **GET** `` — Get Chat By specifying the unique chat ID, this particular endpoint is designed to retrieve comprehensive chat information, excluding the actual messages within the chat, offering a high-level overview of the chat's metadata and attributes - **GET** `` — Get Channels The endpoint to get the channels available to enable the user to contact their users - **GET** `` — Get ICE servers Returns short-lived WebRTC ICE server credentials (STUN/TURN) for establishing peer connections during voice and video calls. - **GET** `` — List chat exports Returns a paginated list of chat export requests for the authenticated client. Supports filtering by request actor, export type, export format, language, date range, and chat ID. - **GET** `` — Get groups counters This endpoint allows the retrieval of group counters such as total open conversations and total online agents on a group by group basis. - **GET** `` — Search Chat Activities This endpoint retrieves a chat's activity history. Optional filters can be applied to refine the search. It provides a comprehensive overview of all activities within a given chat. - **GET** `` — Get Assignment Ruleset This endpoint allows the retrieval of an assignment ruleset by its ID. If the ID is not valid or the ruleset is not found, an appropriate error will be returned. - **GET** `` — Download Process Video Call Recordings Retrieves the video call recordings for a specified process by its ID. If the video call recordings have not been requested before, it is generated first, progressing through: - 202 Accepted → `"file_status"`: `"requested"` - 202 Accepted → `"file_status"`: `"in_progress"` - 302 Found * → Redirects to the video call recordings file when ready - 200 OK → Returns the file If the video call recordings have already been generated, the response immediately returns: - 302 Found * → Redirects to the video call recordings file when ready - 200 OK → Returns the file Polling: If the file is not ready (`202 Accepted`), retry until `302 Found` or `200 OK`. * 302 Redirect Handling: Most API clients and browsers follow redirects automatically. However, if your API client does not, extract the Location header containing the video call recordings's URL and make a GET request to download the file. - **GET** `` — List Outbound Messages This endpoint retrieves a list of outbound messages that have been created. Users can access this endpoint to view and review the outbound messages they have generated or sent, providing an overview of the created outbound messages within the system or application. - **GET** `` — Get Agent Templates This endpoint allows getting the agent message templates of the account. An item limit, message template name prefix and start key can be defined as query params. If any of the query params is invalid, an error message is returned. - **GET** `` — Get agents status This endpoint allows the retrieval of agents online status along with information and open chat counters. - **GET** `` — Get Outbound Message This endpoint retrieves an outbound message. Users can use this endpoint to obtain details or content related to a specific outbound message. - **DELETE** `` — Remove Outbound Message This endpoint allows users to delete an outbound message. Users can initiate the removal process for a specific outbound message, effectively eliminating it from the system or application. It provides a means to manage and clean up outbound messages when they are no longer needed or relevant. - **DELETE** `` — Delete Agent Template This endpoint allows the deletion of an agent message template. The endpoint checks if the template exists; if not, it returns an appropriate error message. ### — Catalogs Manage your catalogs and products in a single place. - **POST** `` — Create Catalog This endpoint allows the creation of new catalog. Users must specify the name and provider type. In the case of a Meta catalog, the user must also specify the vertical. The catalog will be created but it will not be published until the user publishes it. - **POST** `` — Link a catalog to a WABA This endpoint links a catalog to a WABA. Note that if the catalog is unpublished, or if the WABA is already linked to another catalog, or if the catalog is already linked to another WABA, the request will fail. - **POST** `` — Create products for a catalog Creates products and returns a 200 status code. It triggers an async Meta sync if the catalog is published, otherwise storing them as UNPUBLISHED. - **PUT** `` — Update catalog Updates an existing catalog. If the catalog is published, changes are synced with the provider. - **PUT** `` — Update products for a catalog Updates the products and returns a 200 status code. If the catalog is published, it synchronizes the uploaded products with Meta. - **GET** `` — Get Catalogs This endpoint allows the retrieval of all catalogs for a given client with pagination support. - **GET** `` — Get catalog By specifying the unique catalog ID, this particular endpoint is designed to retrieve comprehensive catalog information, offering a high-level overview of the catalog's metadata and attributes - **GET** `` — List products for a catalog Returns products for a catalog with optional filters and cursor pagination (self and next URLs). - **DELETE** `` — Delete catalog Deletes a catalog and all its related items. If the catalog is published on Meta, it is also removed there. Returns an error if the catalog does not exist or the request is invalid. - **PATCH** `` — Mark products for deletion Marks the specified products for deletion in the catalog. Accepts a list of retailer IDs in the request body. After marking, the catalog is republished via the publish products service - **PATCH** `` — Unlink a catalog from a WABA This endpoint unlinks a catalog from a WABA. If the catalog is already unlinked, the request is treated as successful; the request fails if in Meta the WABA is not linked to this catalog or is linked to another catalog. - **POST** `` — Publish a catalog This method publishes a catalog to the external provider (Meta). The catalog must already be linked to the WABA specified in the request body. On success, the catalog is published to the provider and products are synced. ### — WA Contacts Add, search and manage your customers (end users) in a single place. - **POST** `` — Create contact property This endpoint is used to create a new contact property with data like its name and type. NOTE: A maximum of 25 visible (non-hidden) properties can exist simultaneously. - **POST** `` — Create contact This endpoint is used to create a new contact with data such as its phone number, external_id, name, optional email, and values for custom contact properties. At least one of phone_number or external_id must be provided. - **PUT** `` — Update contact This endpoint is used to update a specific contact with the ID provided as a path parameter. The contact's name, email and custom property values can be changed. An optional "emit_sysevent" body parameter can be passed so that the update triggers a sysevent. - **GET** `` — Get contact properties This endpoint is used to list pages of contact properties created in our platform. An optional "start_key" query parameter can be passed to continue pagination. - **GET** `` — Get all contacts This endpoint is used to list pages of contacts created in our platform. An optional "start_key" query parameter can be passed to continue pagination. - **GET** `` — Get contact This endpoint is used to get the data related to a specific contact using the identifier provided as a path parameter. - **DELETE** `` — Delete contact This endpoint is used to delete a specific contact with the ID provided as a path parameter. ### — WA Knowledge Base This API allows management of knowledge bases with multiple repositories for Truora AI. ### — DI Flows You may create, view, and edit flows according to your needs. ### — DI Processes Configure and order the validations you want to do in your process. Try and start validating your users by sending a link. - **POST** `` — Send Process Link This request sends a short link to the user's phone number via the specified messaging channel and in the specified language. The link directs the user to a secure URL to perform or continue their identity validation process. Header Setup: Set the Truora-API-Key header to the same ``api_key`` value used when creating the ``process_id`` (via the Create Identity request). - **POST** `` — Identity Back Allows stepping back in the identity verification process or retrying the last step. - If `retry_step` is true, the last step is re-executed with the same expected inputs. - If `retry_step` is false or not provided, the process moves one step back. - **POST** `` — Feed wallet Exchanges a wallet OAuth code for an access token and pushes the process's document/face validations to /v1/oauth2/validations on the wallet. - **POST** `` — Create log [Internal use] Allows to create logs from front end to send to kibana to keep track of usage - **POST** `` — Verify Identity The Verify Identity endpoint processes each step in an identity verification process. It receives step input data, validates it, and updates the process to the next step. The step input must be provided in the request body according to the specific requirements of each step. To retrieve steps required values and track the process progression use the Read Identity endpoint. Refer to the Verify Identity Steps guide for a practical example of using the Verify Identity endpoint along with other DI Processes endpoints. If you need help with a specific integration scenario, please contact our Support Team. - **POST** `` — Create Identity This endpoint allows you to initiate an identity validation process for a specific user. Before using this endpoint, you must create a Flow and generate a temporary ``api_key`` linked to the corresponding ``flow_id``. Follow the Web Integration Token Guide to complete this setup. The response will include a ``process_id``, which you'll use in subsequent process requests. Important Notes Token: You must generate a unique token (``api_key``) for each identity validation process, even if performed by the same user. Header Setup: Set the Truora-API-Key header to the value of the generated token (``api_key``) required before making this request. - **POST** `` — Add Verification Appends a verification and its first step to an existing dynamic identity process. Only one verification may be active at a time — the request is rejected if another verification is still pending or a step is in flight. - **PUT** `` — Update Identity This API endpoint updates an existing process identified by `process_id`, modifying changeable process information such as phone number and device details until the process is complete. - **GET** `` — Read Variables Retrieves all the variables associated with the specified identity process, including their names and current values. - **GET** `` — List Identity Retrieves the current status and details of all identity processes. Query parameters can be used to filter results based on specific criteria. When a date range is defined, the search is limited to 2 months. The response includes up to 20 processes per query. Note: If a process includes the attributes ``override_status`` and ``override_status_history``, it means the final status was modified by an authorized user. In this case, use the ``override_status`` attribute instead of ``status`` to determine the final status of the process. The ``override_status_history`` attribute will contain the history of changes made to the status. >

Note: Responses for users with the permission identity.process.read.own are limited to their own processes (those they initiated and those linked to them via configured “own” scope variables).

- **GET** `` — Download Process PDF Retrieves the PDF document for a specified process by its ID. If the PDF has not been requested before, it is generated first, progressing through: - 202 Accepted → `"file_status"`: `"requested"` - 202 Accepted → `"file_status"`: `"in_progress"` - 302 Found * → Redirects to the PDF file when ready - 200 OK → Returns the file If the PDF has already been generated, the response immediately returns: - 302 Found * → Redirects to the PDF file when ready - 200 OK → Returns the file Polling: If the file is not ready (`202 Accepted`), retry until `302 Found` or `200 OK`. * 302 Redirect Handling: Most API clients and browsers follow redirects automatically. However, if your API client does not, extract the Location header containing the PDF's URL and make a GET request to download the file. - **GET** `` — Get Result Allows you to retrieve the current status and details of a process. The ``status`` begins as ``pending`` and updates to either ``success`` or ``failure`` when the process completes. - Pending: The process is still ongoing. - Success: All steps in the process have been successfully completed. If the flow includes validators, all ``validation_status`` values must also be successful. - Failure: Occurs due to an internal error, timeout, or if the process is declined or expired. Here's a comprehensive list of reasons why a process or validation might be declined or expired, as recorded in the ``declined_reason`` and ``expired_reason`` fields: - Declined Reasons - Expired Reasons If a process includes validators and the identity process times out because a validation did not complete, but all inputs have been uploaded, the system grants an additional 5 minutes to receive a validation response with the final status. This behavior occurs up to 3 times. On the final attempt to retrieve the validation response, if the validation remains in the ``pending`` status, the identity process status will update to ``failure``, with ``failure_status`` set to ``expired``. If a process includes the attributes ``override_status`` and ``override_status_history``, it means the final status was modified by an authorized user. In this case, use the ``override_status`` attribute instead of ``status`` to determine the final status of the process. The ``override_status_history`` attribute will contain the history of changes made to the status. - **GET** `` — Download Process Video Call Recordings Retrieves the video call recordings for a specified process by its ID. If the video call recordings have not been requested before, it is generated first, progressing through: - 202 Accepted → `"file_status"`: `"requested"` - 202 Accepted → `"file_status"`: `"in_progress"` - 302 Found * → Redirects to the video call recordings file when ready - 200 OK → Returns the file If the video call recordings have already been generated, the response immediately returns: - 302 Found * → Redirects to the video call recordings file when ready - 200 OK → Returns the file Polling: If the file is not ready (`202 Accepted`), retry until `302 Found` or `200 OK`. * 302 Redirect Handling: Most API clients and browsers follow redirects automatically. However, if your API client does not, extract the Location header containing the video call recordings's URL and make a GET request to download the file. - **GET** `` — Read Identity Retrieves the current status and detailed results of the specified identity process, including the progress of each step. >

Responses for users with the permission identity.process.read.own are limited to their own processes (those they initiated and those linked to them via configured “own” scope variables)

- **DELETE** `` — Delete Identity This API endpoint permanently removes an identity process, typically used for legal requests to delete customer data, granted the necessary permissions. Note: This action is definitive, so there is no way to reverse it. ### — Customers Customers is a centralized solution that allows you to visualize and analyze the data generated by the transactions made by your users along different business funnels. - **POST** `` — Query user customers User profile query endpoint allows to obtain detailed statistics on different aspects of user customers - **POST** `` — Compute profile segment Trigger the computation of a profile segment. This will queue the segment for processing and convert the JSONLogic rule to SQL. - **POST** `` — Create profile segment Create a new profile segment with a name, description and JSONLogic rule to define the segment criteria. - **PUT** `` — Update profile segment Update a profile segment with a name, description and JSONLogic rule to define the segment criteria. - **PUT** `` — Update Customer Tags Update customer tags endpoint allows you to update, add, remove, and manage the tags associated with a customer profile. - **GET** `` — List available decision variables This endpoint returns all available decision variables in the system with their metadata, types, allowed values and example values. Supports filtering by search, ID, name, category, active status, product, type, and level. Multiple values can be provided for ID, name, category, product, type, and level filters. This endpoint supports pagination. - **GET** `` — Get Customer Waba Lines Get customer waba lines endpoint allows you to consult the waba lines that have interacted with a customer. - **GET** `` — List decision variables for user customers Allows to obtain decision variables for user customers by search, date range, categories and names. This endpoint supports pagination. - **GET** `` — List Customers This API endpoint allows retrieving the current status and general information of all customers associated with an account. - **GET** `` — Get Customer Transaction Get customer transaction endpoint allows you to consult the detailed information of a transaction associated with a customer. - **GET** `` — List profile segments This API endpoint allows retrieving all profile segments associated with the authenticated client. The response includes pagination support through start_key and limit query parameters and can be filtered by segment name with search. - **GET** `` — List Customers Transactions List customer transactions endpoitn allows you to consult the detailed information of the transactions associated with a customer. - **GET** `` — Get profile segment The API endpoint allows retrieving the details of the segment identified by the provided ID. - **GET** `` — Get Customer Tag History Get customer tag history endpoint allows you to consult the detailed information of the tag history associated with a customer. - **GET** `` — Get Customer This API endpoint allows retrieving the details of the customer identified by the provided ID. - **GET** `` — List segment profiles Returns the profiles that belong to the requested segment and supports cursor-based pagination through the start_key query parameter. - **DELETE** `` — Delete profile segment This API endpoint allows you to delete a profile segment. It removes the segment from the system, including all associated rules and configurations. The response includes a success message indicating that the segment has been deleted. ### — Status Status lets you check the current state of our services in real time. ## Truora Pass Truora Pass lets your users verify their identity once and reuse it to sign in across apps. It is a standard OAuth 2.0 / OpenID Connect provider: your application redirects the user to Truora Pass to authenticate and consent, exchanges the resulting authorization code for tokens, and reads the user's verified identity claims from the UserInfo endpoint. Start with the [Getting started](/truora-pass/getting_started/) guide, register your application following [Registering your application](/truora-pass/registering_your_application/), and see the [Scopes reference](/truora-pass/scopes_reference/) for scope details. Detailed flow guides: [Authorization Code flow](/truora-pass/authorization_code_flow/), [Embedded SDK](/truora-pass/embedded_sdk/), [CIBA flow](/truora-pass/ciba_flow/), [Refresh tokens](/truora-pass/refresh_tokens/), [UserInfo and claims](/truora-pass/userinfo_and_claims/), [Verification results](/truora-pass/verification_results/) and [Errors and troubleshooting](/truora-pass/errors_and_troubleshooting/). The authorization page (`GET /authorize`) is served from `https://pass.truora.com`; every JSON/form API below is served from the base URL `https://api.pass.truora.com`. Truora Pass does not publish an OIDC discovery document, JWKS, or a token revocation endpoint — the endpoints below are the complete public surface. ## Scopes Request scopes space-delimited on `/authorize` and `/bc-authorize`. Every requested scope must be registered for your application. Scopes marked **sensitive** require a `binding_message` on CIBA requests; **restricted** scopes are enabled per client by Truora.

Scope	UserInfo claims it unlocks	Notes
`openid`	`sub`; enables the `id_token`
`email`	`email`, `email_verified`
`phone`	`phone_number`, `phone_number_verified`
`profile`	`name`, `first_name`, `last_name`, `gender`, `birthdate`, `nationality`, `updated_at`
`identity`	`identity_verified`, `verification_level`, `given_name`, `family_name`, `birthdate`, `nationality`, `document_number`, `document_type`, `issuing_authority`, `is_risky`, `was_manually_reviewed`, plus `document_expired` and `expiration_date` when the primary document is expired
`documents`	`documents` array	sensitive; equivalent to `document:ALL:ALL`
`document:<COUNTRY>:<TYPE>`	`documents` filtered to the country/type	granular form — `<COUNTRY>` is lowercase ISO 3166-1 alpha-2 or `ALL`, `<TYPE>` a known document type or `ALL`
`age`	`age_verified`; with a birthdate on file: `is_minor`, `age_range`, `birthdate`
`address`	`address` object
`background`	`trust_level`, `background_verified`, `verification_badges`, `manual_verification_status`	sensitive; refreshes an in-progress background check before responding
`biometric`	`face_enrolled`, `last_face_verification_date`, `liveness_check_passed`, `face_match_confidence`, `quality_level`, `verification_method`
`verification`	`verification_status`, `verification_date`, `verification_methods`
`contact`	`email`, `email_verified`, `phone_number`, `phone_number_verified`, `preferred_communication_method`
`nationality`	`nationality`
`documents:images`, `biometric:image`	— (image delivery; no UserInfo claims today)	sensitive
`approval:read`	—	gates `GET /oauth2/approval-outcome`
`validations:write`	—	sensitive, restricted; gates `POST /oauth2/validations`
`google:drive:readonly`, `google:docs:readonly`, `google:sheets:readonly`, `google:gmail:readonly`, `google:calendar:readonly`	`google_tokens` / `google_tokens_status`	restricted; Google delegated access via the user's consent

Detailed aliases (`profile:detailed`, `identity:basic`, `identity:full`, `document:passport`, `age:exact`, `address:full`, `background:summary`, `verification:detailed`, `contact:full`, `biometric:status`, …) are accepted and normalized to the flat scopes above. **Base URL:** `https://api.pass.truora.com` ### — Authorization Front-channel authorization. Redirect the user's browser to the `/authorize` page on `https://pass.truora.com` to start the Authorization Code flow; the user authenticates and consents, and Truora Pass redirects back to your registered `redirect_uri` with a single-use authorization code. The [Embedded SDK](/truora-pass/embedded_sdk/) drives this same endpoint inside a modal using `response_mode=web_message`. **Authentication strength (`acr_values`).** You may require a minimum authentication level; Truora Pass steps the user up when their session is weaker. The effective requirement is the stronger of your request and the floor configured for your application.

ACR	Meaning
`urn:truora:acr:0`	Guest / no authentication
`urn:truora:acr:1`	Single factor (password, federated sign-in, email OTP)
`urn:truora:acr:2`	Strong single factor (passkey / WebAuthn)
`urn:truora:acr:3`	Multi-factor with biometrics (factor + face)

The level actually achieved is returned in the `id_token` `acr` claim; the methods used are in `amr` (RFC 8176 values: `pwd`, `webauthn`, `face`, `federated`, `otp`, `anon`). - **GET** `` — Start the Authorization Code flow Redirect the user's browser to `https://pass.truora.com/authorize` with the query parameters below. After the user authenticates and consents, Truora Pass redirects back to your `redirect_uri` with `code` and `state` query parameters on success, or `error`, `error_description` and `state` on failure. The authorization code is single-use and expires after 10 minutes. Some failures are rejected inside Truora Pass without redirecting back (your callback never fires): a `redirect_uri` mismatch, an unregistered scope, an invalid `response_type` or `response_mode`, `web_message` not enabled or the origin not allow-listed, and step-up conditions such as `acr_not_satisfied`, `session_too_old` or `email_domain_not_allowed`. ### — Tokens Back-channel token endpoint. A single endpoint multiplexed by `grant_type`: exchange an authorization code for tokens, rotate a refresh token, or poll a CIBA (decoupled) authorization request. Requests carry your `client_secret` and must always run server-to-server — never in the browser. **Token lifetimes.** Authorization codes are single-use and expire after 10 minutes. Access tokens live 60 minutes. Refresh tokens are single-use and rotate on every redemption with a 365-day sliding lifetime — reusing an already-used refresh token revokes the whole token family. **ID token.** Issued only when the `openid` scope is granted (authorization-code and CIBA grants; never on refresh). It is a JWT that expires after 5 minutes, with claims:

Claim	Value
`sub`	The user's stable Truora Pass identifier
`iss`	`https://pass.truora.com`
`aud`	`[<your client_id>]`
`iat`, `exp`	Issued-at / expiry (5 minutes)
`jti`	Unique token ID
`auth_time`	When the user authenticated (when available)
`acr`	Authentication level achieved (see Authorization)
`amr`	Authentication methods used (RFC 8176)
`at_hash`	CIBA only — left-half SHA-256 hash of the access token
`urn:openid:params:jwt:claim:auth_req_id`	CIBA only — the authorization request ID

- **POST** `` — Exchange a code, rotate a refresh token, or poll CIBA Server-to-server only — this request carries your `client_secret` and must never run in the browser. **Grant `authorization_code`** (JSON): exchange the single-use code from the callback for tokens. Send `grant_type`, `code`, `client_id`, `client_secret` and `redirect_uri` (must match the authorize request). Returns `access_token`, `token_type` (`Bearer`), `expires_in` (3600), `scope`, a `refresh_token`, and an `id_token` when the `openid` scope was granted (expires after 5 minutes). **Grant `refresh_token`** (JSON): rotate a refresh token without re-authorizing the user. Send `grant_type`, `refresh_token`, `client_id`, `client_secret`, and optionally `scope` to down-scope (a subset of the originally granted scopes). Refresh tokens are single-use and rotate on every call (365-day sliding lifetime): the response contains a NEW `refresh_token` — replace the stored one. Reusing an already-used token revokes the whole token family. No `id_token` is returned. **Grant `urn:openid:params:grant-type:ciba`** (form-encoded): poll for tokens after a [backchannel authorization request](/truora-pass/ciba_flow/). Send `grant_type`, `auth_req_id`, `client_id` and `client_secret`, waiting at least `interval` seconds between polls. While the user has not decided the response is `400 authorization_pending`; once approved it returns tokens (no `refresh_token` for this grant). ### — Backchannel (CIBA) Decoupled authorization (OpenID CIBA). Start an authorization request for a user identified by email; Truora Pass delivers an approval link to the user's verified phone over WhatsApp, and your backend polls the token endpoint until the user approves or declines. Requires the CIBA grant to be enabled for your application — contact Truora. Beyond plain authorization, CIBA requests can carry rich `authorization_details` (RFC 9396) for approval-style consent (the user reviews and approves a concrete action, optionally filling a form). Use `POST /v1/oauth2/approval-attachments` to stage files shown on the approval screen, and `GET /v1/oauth2/approval-outcome` to read the decision and any submitted form data afterwards. - **POST** `` — Start a backchannel authorization request Starts a decoupled authorization request for the user resolved by `login_hint` (email). Truora Pass sends the user a WhatsApp approval link to their verified phone; your backend then polls `POST /v1/oauth2/token` with the returned `auth_req_id` and the CIBA grant type, waiting at least `interval` seconds between polls. Requires the CIBA grant to be enabled for your application (contact Truora). The resolved user must have a verified phone. When a sensitive scope (`documents`, `background`) is requested, `binding_message` is required and is shown on the approval screen (truncated to 200 characters). - **POST** `` — Stage an approval attachment Stages a file to be shown on a CIBA approval screen (e.g. the contract the user is asked to approve). Returns a presigned `upload_url` — PUT the file bytes there directly; they never pass through Truora Pass. Reference the returned `s3_key` from the `attachments` of your `authorization_details` on the subsequent `POST /v1/oauth2/bc-authorize`. The attachment is keyed to the future approver by `login_hint` (email), so it can be staged before the user has a Truora Pass account. Allowed content types: `image/png`, `image/jpeg`, `image/gif`, `image/webp`, `application/pdf`, `text/plain`, `text/markdown`, `text/csv`, `application/json` (active content is refused). Maximum object size 10 MiB; the upload URL expires after 10 minutes; `file_name` is sanitized and limited to 200 characters. - **GET** `` — Read an approval outcome Returns the reviewer's decision for a CIBA approval request, plus any form data they submitted on the approval screen (the token response has no room for it). Authenticate with a Bearer access token that carries the `approval:read` scope; the approval must belong to your application. ### — UserInfo Read the user's verified identity claims. The response is a JSON map whose keys depend on the scopes granted to the access token — see the Scopes table above for the full claim-to-scope map. - **GET** `` — Read the user's verified identity claims Returns a JSON map of the user's verified identity claims for the scopes granted to the access token. `sub` is always present; empty claims are omitted. When the `background` scope is granted, background data is refreshed before responding. See the Scopes table above for the complete claim-to-scope map. When the token carries Google-delegated scopes (`google:*`), the response additionally includes `google_tokens` (`access_token`, `refresh_token`, `expires_at`, `scopes`) or `google_tokens_status` (`re_consent_required` when the user must re-consent). Send the access token as a Bearer token: `Authorization: Bearer `. ### — Validations (restricted) Append-only write of externally performed identity validations into a user's Truora Pass profile. Restricted — available only to client applications allow-listed by Truora, with the sensitive `validations:write` scope granted. - **POST** `` — Write identity validations Appends externally performed identity validations (document and/or face) to the user's Truora Pass profile. **Restricted** — your client application must be allow-listed by Truora and the access token must carry the sensitive `validations:write` scope. Send 1 to 100 items. Each item is `type: document` (requires the `document` object with at least `document_number` and `document_type`) or `type: face` (requires the `face` object). Providing a `process_id` makes the write idempotent: replaying a request whose `process_id`s were all already recorded returns `200` with an empty list instead of creating duplicates. ## Main Validator Suite API **NOTE:** Truora provides a [**Postman collection online**]( https://www.postman.com/truora-api-docs/workspace/truora-api-docs/collection/26510995-ad2e7c71-b39a-40e4-8322-ae3316160634?ctx=documentation) that includes the necessary tools to simplify the testing process. Welcome to the Truora Validators Suite [RESTful](https://en.wikipedia.org/wiki/REST) API Reference. If you haven't already, we strongly advise you to check out our Validators API Documentation. Here, you'll find detailed technical information about our Validators API endpoints, including parameters, request and response formats, error codes, and supported methods for seamless integration. The Validators Suite supports various use cases, such as document validation, phone and email verification, facial recognition, and more. A validation process may include some or all of the following steps, depending on the validator: - Create Enrollment: Required to associate user data for validators requiring prior information, such as face, email, and phone. - Create Validation: Required for all validators; you must specify the validator type and relevant validation parameters. - Perform Validation: Executes asynchronous validations, such as email or phone, by verifying tokens received by the user. - Get Validation: Retrieves the final status, results, and details of any validation. Please keep in mind that in our validation processes, the Account ID serves as a unique user identifier, allowing you to track the validations performed. It is important to generate a distinct identifier for each user undergoing validation to prevent data overlap between users and ensure proper monitoring for each one. For conceptual overviews, implementation guides for each validator, and additional resources to enhance your integration experience, please visit our Validators API Documentation.

Authentication

Note: This request will soon be deprecated. Please use the Get Validation (GET /v1/validations/{validation_id}) request instead.

Retrieves the detailed information of a specific validation using an ``account_id`` and ``validation_id``. This object is useful for understanding the exact status of the validation process. You can retrieve the current status and results of a validation, where the ``validation_status`` begins as ``pending`` and can either be ``success`` or ``failure`` upon completion. To obtain details such as the inputs or uploaded media for the validation, you can include the query parameter ``show_details`` with the value of ``true``. To learn more about the reasons for failure, please refer to the following guides: - Expired Reasons - Declined Reasons ### — Aliases The Aliases feature allows you to link multiple identifiers—such as an email, phone number, username, or any custom ID—to a single validated account ID, enhancing flexibility and ease of identity management across Truora's services. This setup enables users to select their preferred identifier, streamlining processes like registration, login, account recovery, and multi-identifier systems. For more details and examples, see our guide on Using Aliases. ### — Flows A flow represents an ordered series of steps to validate a person identity. Check out our Guide on Flows to learn more. ### — Processes Processes represent the execution data of the steps in the flow with a validator. You can verify the validation results for each step or in general, and it allows you to handle backtracking steps whenever necessary within the same validator. ### — Verifications Allows listing the verifications performed. ### — Enrollments The enrollment step is crucial in our system, as it connects an account with a specific validation type. This process allows you to register a user once and perform multiple validations seamlessly. The required fields for an enrollment vary depending on the validation type. Note that enrollment is mandatory for all validators except document validation. - **POST** `` — Create Enrollment This is the first step in validation processes like Face Search, Face, Phone, and Email validation. It requires the submission of necessary images or base information. During enrollment, essential materials, such as photographs or other relevant data, are collected to serve as the basis for user verification. It is important to emphasize that the actual validation will take place in later steps, using the information gathered during this stage. This step is crucial to ensure the system has all the necessary elements to perform an accurate and effective evaluation in subsequent stages. - **GET** `` — Get Enrollments by Account Retrieves all enrollments linked to a specific ``account_id``. Each enrollment object includes its status and other relevant details. Enrollment status begins as ``pending`` and can ultimately result in either ``success`` or ``failure``. For more information about declined enrollment reasons, please refer to the Declined Reasons Guide. - **GET** `` — Get Enrollment Allows you to search for an enrollment to verify its progress. Using this step is optional. The enrollment status begins as ``pending`` and can ultimately result in either ``success`` or ``failure``. For more information about declined enrollment reasons, please refer to the Declined Reasons Guide. - **DELETE** `` — Delete enrollment Deletes an enrollment. If this endpoint is executed on an enrollment ID, the enrollment will be removed from the client's account. ### — Validations Validations is your tool for managing various validators such as document validation, face recognition, face search (TruFace), email verification, and phone verification. This API handles all the necessary logic for these validators, offering a unified service to manage multiple validators efficiently. - **POST** `` — Create Validation Creates a new validation for the specified validation type. This process allows your company to confirm that the user's identity matches the provided information (such as documents, images, videos, or codes like OTP), ensuring accuracy and security in the verification process, which is crucial for legal responsibilities. - **POST** `` — Perform validation Perform validation for the specified ``validation_id``. If a previous validation attempt was unsuccessful, this will count as a retry, which could occur due to errors such as a typo in the token or other mistakes. - **POST** `` — Restores a previously deleted validation and its associated data The data restoration endpoint restores a previously deleted validation record and all linked user data across Truora services - **PUT** `` — File Upload Allows the upload of binary files, such as images or videos, needed for document validation or person verification. To upload a file, make a PUT request to the URL provided during the validation or enrollment process. - **GET** `` — Get Account Validations Retrieves all validations linked to a specific ``account_id``. Each validation object includes its validation status, expired reason, failure reason and other relevant details. Validation status begins as ``pending`` and can ultimately result in either ``success`` or ``failure``. For more information on failure reasons, please refer to the following guides: - Expired Reasons - Declined Reasons - **GET** `` — Get Validation from Account >

Note: This request will soon be deprecated. Please use the Get Validation (GET /v1/validations/{validation_id}) request instead.

Parameters	Document Validator	Face Validator	Phone Validator	Email Validator
timeout	X	X	X	X
allowed_retries	X	X	X	X
retry_ttl	X	X	-	-

Config by Validator Type Each Validator has its own particularities and specific parameters (not listed in the table above) that you may modify to better suit your company's needs. To learn about specific configurable parameters, default values, and special considerations, please visit the guide for the validator you want to configure: - Document Validator Config - Face Validator Config - Email Validator Config - Phone Validator Config NOTES: - The Config Validators parameters are global to your account and will affect all validations performed across it. - However, validations performed in a Flow will prioritize the configuration in the Validator Block of your flow. All other parameters, not configurable within the Flow Builder, will take the global configuration values. To learn about flows, please visit the Create your first flow guide from our Digital Identity documentation. - **PUT** `` — Update config Allows updating the values of various parameters to improve the behavior of the validators, such as timeout, allowed retries, threshold, manual review, among other properties from our validators. For more datails about customizable parameters for each validator, please refer to the individual configuration guides: - Document Validator Config - Face Validator Config - Email Validator Config - Phone Validator Config - **GET** `` — Get Config Fetches the current configuration state for all validators associated with your account. **Note:** Since the response includes configuration details for all validators linked to your account, please review the specific validator details you’re interested in carefully. - **DELETE** `` — Delete Config Allows you to delete a validator’s configuration or a specific parameter (``type``) within the validator’s configuration. Deleting the configuration resets its values back to their defaults.

Note: If you omit the ``type`` parameter when sending the request, all configurations associated with the ``validator`` will be deleted, reverting all values to their default settings. ### — Status Status lets you check the current state of our services in real time. - **GET** `` — Get status Checks the current availability of the validations API. If this endpoint fails, it means the validations api is down and should contact support.