About

Below is a log of changes to the Persona API. Updates that affect only products or features in beta or limited release may not be reflected.

Each change can be described as either a breaking change or an ongoing change.

  • Breaking changes = new API version: When we make any backwards-incompatible changes, we release a new version of the API. In addition to being assigned a new API version, these changes are marked in the changelog with the 💥 symbol. You’re in charge of when you get breaking changes—you get them when you upgrade your API version. Learn how to try out and upgrade to newer API versions.
  • Ongoing changes: Ongoing changes are backwards-compatible, and are added on an ongoing basis. You don’t need to update your API version to get these updates.
SDK changelogs

Each Persona SDK has a separate changelog: Android SDK, iOS SDK, React Native SDK, Javascript SDK, Inlined React SDK, Inlined Vue SDK

Key

🌱 New feature

🍃 Improvement

🔧 Fix

💥 Breaking change

🔒 Security-related

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.