VeraFi API Field Formats

Strings

String fields appear throughout the API, representing user information, tenant identifiers, configuration keys, document field labels, confidence color names, and extracted OCR text. Because the system integrates with OCR, liveness detection, and face verification, many of these string values reflect the formatting present in the original uploaded documents. It is common for OCR-generated strings to include irregular spacing, punctuation variations, or inconsistencies in casing. These are intentionally preserved to maintain the authenticity of the extracted data.

In addition, many string values such as display labels, group names, or document-field titles are determined by tenant-defined document schemas. This means that two tenants may receive different string outputs for the same verification workflow. For this reason, client systems should base their logic on field keys rather than relying on display labels that may change over time.

Numbers

Numerical fields appear in the API wherever counts, thresholds, or usage metrics are required. Verification logs return numeric values indicating the number of verifications performed by a user or the number of records retrieved during pagination. Subscription endpoints return numerical representations of pricing, usage limits, and available report counts. Confidence code configurations also rely on numerical thresholds that define color-based boundaries for critical and non-critical fields.

These values are never static across all tenants. For instance, the confidence thresholds used to determine whether a field is categorized as green, amber, or red are stored in tenant-specific configuration. As a result, tenants may use entirely different numerical ranges for these thresholds. Integrators are expected to interpret these numeric values exactly as returned by the API instead of relying on predefined assumptions.

Dates

Date fields are returned as strings and appear primarily in subscription-related endpoints, tenant onboarding, and reporting. These dates represent values such as subscription start dates, expiration dates, or the dates associated with usage summaries. Since these values are generated by different services within the platform, their visual formatting may vary. Clients are responsible for parsing and formatting these date strings according to their application requirements.

Datetimes

Datetime values appear across OTP operations, verification logs, and audit-related endpoints. These timestamps indicate when an OTP was generated, when it expires, or when a verification or configuration event occurred. The formatting of these values depends on the service that produced them but is always returned as a JSON string suitable for downstream parsing.

OTP datetime-related fields are particularly important because they reflect strict timing rules enforced by the platform. Clients must use these values directly, as any attempt to recalculate OTP expiry or resend windows may result in inconsistencies with VeraFi’s internal logic.

Enums

Enumerations appear in several responses throughout the API. These may include verification module names, document type categories, feature keys, subscription tiers, or color-code identifiers. Many enums are dynamically generated from tenant configurations or feature definitions stored in the system. Because document schemas and feature assignments can change without requiring a new API version, integrators should avoid treating enumeration sets as static. Any logic related to enums must be capable of adapting to new values introduced through configuration changes.

Identifiers

Identifiers are used across the platform to uniquely represent tenants, users, document types, sessions, logs, pricing entries, and subscription services. These identifiers are alphanumeric and are generated internally by the system. They should be treated as opaque values and not parsed or manipulated by client applications. Session identifiers also play an important role in encrypted storage, as any stored media related to a verification session is preserved under a directory associated with its session ID.

VeraFi API Specific Field Formats

Several field formats in VeraFi are essential for understanding how the system processes documents, verification results, and configuration rules. The below metioned are some of them:

Base64-Encoded Media Fields: Many verification workflows require the submission or processing of images and videos in Base64-encoded form. Document uploads, face verification requests, liveness checks, and bank statement submissions all use Base64 strings to transport media securely over the API. These encoded values must be passed exactly as produced during encoding, without trimming whitespace or altering formatting. When storage is enabled for a tenant, these Base64 media files are later encrypted and placed into a structured output folder associated with the session.

JSON Configuration Fields: A significant portion of the VeraFi platform is driven by configuration values stored within the system rather than fixed API schemas. Verification rules, confidence code definitions, document type schemas, feature enablement, and UI behavior are all stored as structured JSON objects. The API returns these objects exactly as they exist in the configuration database, meaning the format may differ from one tenant to another. Client integrations must therefore parse configuration objects dynamically and avoid assuming a fixed structure.

Color Code Fields: Confidence code fields determine the confidence level associated with extracted document values. These fields typically include a color name, the minimum and maximum percentages associated with that color, and sometimes a hexadecimal representation used for UI display. These confidence ranges are fully configurable, allowing each tenant to define its own interpretation of acceptable or critical confidence levels.

Document Schema Formats: Document verification results follow schemas defined entirely by the tenant’s configuration. These schemas specify field names, groupings, display ordering, criticality flags, weightage values, and nested structure definitions. Any changes made to a document type such as renaming a field or altering criticality take effect immediately and influence all subsequent verification responses. Integrators must therefore treat document schemas as dynamic and respond accordingly.

OTP Timer and Duration Fields: Unlike traditional timestamp fields, OTP endpoints return duration-based values that indicate how many seconds remain before an OTP expires or when a new OTP may be requested. These are integer values that reflect the platform’s internal timing logic. Clients must display and act on these durations as returned, ensuring that timing behavior remains consistent with backend rules.

Feature and Subscription Mapping Formats: Feature and subscription management endpoints return structured mappings that define which features are available to a tenant and how those features are grouped. These mappings typically contain feature keys, main feature categories, and hierarchical lists of sub-features. Because subscription configurations may evolve, the structure of these mappings can change over time, and clients should be prepared for new feature keys or categories to appear.

Storage and Encryption Flags: The API provides configuration fields that determine whether uploaded media should be stored and, if so, how it should be encrypted. When storage is enabled, media files are encrypted using AES and stored within a session-specific directory. The encryption key used for this process is retrieved dynamically from the configuration database. Whether stored assets include document photos, ID images, or liveness videos depends entirely on the tenant’s assigned storage flags.

VeraFi’s field formats combine fixed JSON principles with highly dynamic, configuration-driven structures. By understanding and accommodating the full range of field types including Base64 media, configuration objects, confidence codes, document schemas, and encrypted storage rules integrators can build resilient and future-proof applications that adapt seamlessly to tenant-specific configurations and platform updates.