Changelog

Inquiries

• 🍃 Add optional session tokens or one time links to Inquiry creation responses: The Inquiry create response can now return a session token or a one time link if you pass in certain flags. If you pass in auto-create-inquiry-session as true, the response includes a meta.session-token attribute. If you pass in auto-create-one-time-link as true, the response includes meta.one-time-link and meta.one-time-link-short attributes.

• 🍃 Inquiry creation iOS App Attestation improvement: Inquiry create requests now accept meta.ios_app_attest_team_id and meta.ios_app_attest_bundle_id to allow iOS App Attestation on multiple apps on a single Inquiry Template. The properties override the template level configs and accepts either credential or both as overrides.

Reports

• 🍃 Add Instagram URL and username to Social Media Reports: The response attributes for Social Media Reports now include an instagram_url and instagram_username attribute to represent the linked Instagram account. See the Retrieve a Report endpoint for details.

Reports

• 🍃 Add position topics, start dates, and end dates to Politically Exposed Person Reports: The positions attribute in Politically Exposed Person Reports now exposes position topics as well as the start and end dates indicating the duration each position was held. See the Retrieve a Report endpoint for details.

Events

• 🍃 Add context attribute to Events and Webhook Events: Events and Webhook Event resources now include a context attribute that can hold additional information for certain event types. To start, the account.added-relation and account.removed-relation events will have relation-schema-key and target-account-id attributes within context.

Accounts

• 🌱 Add endpoint to search Accounts: You can now use complex queries to search for Accounts via the search endpoint. Using search is a faster alternative to using the list all Accounts endpoint. It is not appropriate for read-after-write flows because the data is not immediately available to search.

Cases

• 🌱 Add endpoint to search Cases: You can now use complex queries to search for Cases via the search endpoint. Using search is a faster alternative to using the list all Cases endpoint. It is not appropriate for read-after-write flows because the data is not immediately available to search.

Reports

• 🌱 Add endpoint to retrieve Report history: You can now retrieve the full audit history of the report, including the scheduled and ad-hoc report runs + report actions from a dedicated endpoint.

API version: 2025-12-08

Reports

• 💥 Stop returning Report run-history: Report responses no longer include the run-history attribute.

  Migration: Clients should call the List Report history endpoint to retrieve the run history of a Report by its ID.

Government ID Documents and Verifications

• 🍃 Surface non-Latin name extractions: Government ID Document and Verification resources now include native_name_first, native_name_middle, native_name_last, and native_name_title.

API version: 2025-10-27

This version improves performance and consistency across endpoints for different products.

Cross-API

• 💥 Stop returning full relationship representations by default: All endpoints no longer return fully serialized relationship objects within the included array by default. To receive full representations, clients must now explicitly pass the include query parameter (for example, ?include=account,inquiry).

  Migration: When upgrading to this version, update any client code that relied on implicit relationship inclusion to add the appropriate include query parameter for the relationships you need. See the inclusion of related resources guide for more details.

• 💥 Stop applying key inflection to data.attributes.fields: For endpoints returning Cases, Transactions, or Inquiries, key inflection no longer applies to field names within data.attributes.fields. Keys now appear using the original inflection scheme configured for the field on the corresponding Case template, Inquiry template, or Transaction type.

  Migration: Update any client code that accesses custom field keys to use their configured inflection style instead of the previously transformed keys. Review API key inflection and the Fields integration guide for reference.

• 🍃 Sparse fieldset improvements: Two improvements now apply to how sparse fieldsets work with the fields[TYPE] query parameter:

  1. Parent type filtering: When you specify a parent resource type in a sparse fieldset, the filtering now automatically applies to all related subtypes. Example: If you filter by fields[report]=status, the filtering now also applies to all specific report types like report/business-lookup, report/watchlist, etc.
  2. Inflection normalization: Attribute names in the value of the fields parameter are now normalized, meaning you can use kebab-case, snake_case, or camelCase interchangeably. Previously, you had to match the inflection of the attribute keys exactly to what would be returned in the response.

Accounts

• 💥 Remove Persona-provided PII fields from Account response: Persona-provided PII fields (e.g. name_first, name_last, birthdate) are now only accessible in data.attributes.fields.

  Migration: Clients should access the data.attributes.fields object from the Account resource. Field keys will not be inflected.

• 💥 Don’t return full Account resource for HTTP 409 responses: In some cases for older API versions, a full Account resource would be returned with an HTTP 409 (Conflict) response. This is now consistent: all 4xx response bodies include an error detail instead of a full Account resource.

Cases

• 💥 Ignore custom fields from Case create and update requests: Customer-defined fields are no longer valid top-level parameters for Case create and update requests. They can now only be specified in data.attributes.fields.

  Migration: Client requests should pass their values under data.attributes.fields instead of at the top level. This object should be a map where the keys are field keys and values are the intended field value. Field keys should not be inflected.

• 💥 Require status to be passed in meta when setting Case status: The set status on Case endpoint request body now requires the status value to be passed in meta instead of in data.attributes. Passing status within data.attributes is no longer accepted.

  Migration: Update all client requests that call the set status on Case endpoint to include status inside the meta object.

Inquiries

• 💥 Ignore Persona-provided fields and custom fields from Inquiry create and update requests: Persona-provided PII fields and customer-defined fields are no longer valid top-level parameters for Inquiries create and update requests. They can now only be specified in data.attributes.fields.

  Migration: Client requests should pass their values under data.attributes.fields instead of at the top level. This object should be a map where the keys are field keys and values are the intended field value. Field keys should not be inflected. Commonly used attributes that may need to be moved include name_first, name_last, country_code, and address fields. As a special case, the top-level attribute country_code previously corresponded to the Persona-provided field selected_country_code. Users of this attribute should instead pass data.attributes.fields.selected_country_code.

• 💥 Remove Persona-provided PII fields from Inquiry response: Persona-provided PII fields (e.g. name_first, name_last, birthdate) are now only accessible in data.attributes.fields.

  Migration: Clients should access the data.attributes.fields object from the Inquiry resource. This object is a map where the keys are field keys and values are a map with keys type, which specifies the data type, and value, which specifies the collected value. Field keys are not inflected.

List Items

• 💥 Remove inquiry_matches attribute from List Item response: List Item resources no longer include the inquiry_matches attribute. In previous versions, this was always an empty array.

Reports

• 💥 Remove legal_entity_type field from individual registry records: Individual registry records no longer include the legal_entity_type field in Business Registrations Lookup Reports (BRRs). This field has historically been null for individual registry records and continues to be populated at the top level of the Report based on domestic registration data.

Transactions

• 💥 Limit size of related-objects relationship in Transaction responses: The amount of related-objects that can be returned as part of a Transaction resource is now limited to 100. Transactions can have more than 100 related objects, but only the first 100 are present on Transaction responses.

Verifications

• 💥 Deprecate database_business_ai_identity_comparison check: The database_business_ai_identity_comparison check is now deprecated. All AI-powered identity comparison results are now available in database_business_identity_comparison. This consolidation simplifies data retrieval by unifying AI and rules-based comparison outputs under a single check type.

Workflow Runs

• 💥 Require fields to be passed in data.attribute.fields when creating Workflow Runs: The create a Workflow Run endpoint request body now requires fields to be passed in data.attributes.fields instead of meta.params or data.attributes.

  Migration: Client requests should pass their values under data.attributes.fields instead of at the top level or through meta.params. This object should be a map where the keys are field keys and values are the intended field value. The schema is defined by the trigger payload schema on your Workflow Version.

Accounts

• 🌱 Add endpoint to run an Account action: You can now run an account action via API.

User Audit Logs

• 🍃 Add context.inquiry_id attribute to User Audit Logs: User Audit Log resources now include a context.inquiry_id attribute to retrieve the inquiry-id of an inquiry created via dashboard.

Tags

• 💥 Active tags limited to 1000 per organization: API requests that would create additional tags receive a 422 response code if the organization has at least 1000 tags currently active.

Verifications

• 🍃 Add non-domiciled to the list of possible ID designations: non-domiciled is now among the list of possible ID designations.

Lists

• 🍃 Allow creating String Lists via API: You can now create String Lists via API.

Accounts

• 🍃 Allow filtering Accounts by multiple reference IDs: You can now list all Accounts by filtering on an array of reference IDs.

Verifications

• 🍃 Add account relationship to Verifications: Verification resources now include the related account in data.relationships. This allows you to determine which Account a given Verification is associated with directly from the response, without making an additional query.