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.

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 will 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 will no longer be applied to field names within data.attributes.fields. Keys will 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: We’ve made two improvements 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 will now also apply 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) will now only be 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. We’ve made this consistent so all 4xx response bodies will include an error detail instead of a full Account resource.

Cases

  • πŸ’₯ Ignore custom fields from Case create and update requests: Customer-defined fields will no longer be 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 will no longer be 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 will no longer be 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) will now only be accessible in data.attributes.fields.

    Migration: Clients should access the data.attributes.fields object from the Inquiry resource. This object will be 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 will not be inflected.

List Items

  • πŸ’₯ Remove inquiry_matches attribute from List Item response: List Item resources will 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: The legal_entity_type field has been removed from individual registry records 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 will be present on Transaction responses.

Verifications

  • πŸ’₯ Deprecate database_business_ai_identity_comparison check: The database_business_ai_identity_comparison check has been 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 create 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.



Tags

  • πŸ’₯ Active tags limited to 1000 per organization: API requests that would result in additional tags being created will receive 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.



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.


Cross-API

  • πŸƒ Add page-count to File field schema: Responses that include field schemas with type FieldSchema::File will include the page count for newly created files or files with updated parent Persona object (Inquiry/Account/Transaction). Non-PDF format files will default to a page count of 1.

API Keys

  • πŸƒ Extend maximum file access token expiry to 3 days: API keys can now be configured (via the file-access-token-expires-in parameter) to return file URLs that have access tokens that are valid for up to 3 days. The previous maximum was 1 day. For more info, see Downloading Files.

Webhooks

  • πŸƒ Extend maximum file access token expiry to 3 days: Webhooks can now be configured (via the file-access-token-expires-in parameter) to return file URLs that have access tokens that are valid for up to 3 days. The previous maximum was 1 day. For more info, see Downloading Files.

User Audit Logs

  • πŸƒ Add response-status attribute to User Audit Logs: User Audit Logs resources now include a response-status attribute, which indicates the HTTP response of the request.
  • πŸƒ Update get-params and post-params typing: User Audit Logs get-params and post-params attributes can now be a string in addition to an object.

Verifications

  • πŸƒAdd tags attribute to Verifications: Verifications resources now include tags that are associated with the verification.

Workflows

  • πŸƒΒ Access workflow deployment and version details: You can now request the active-deployment and latest-published-version information via include when querying for a specific workflow.

Accounts

  • πŸƒ Add max-file-size-bytes to File field schema: File field schemas now include a max-file-size-bytes attribute. This allows you to specify the maximum file size (in bytes) that can be uploaded for a given file field. The default is 10,000,000 bytes (10MB). This gives developers finer control over file uploads when designing templates and forms.