> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.withpersona.com/2020-05-18/api-reference/versioning/changelog/2025/10/27/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.withpersona.com/_mcp/server.

### Government ID Documents and Verifications

* 🍃 **Surface non-Latin name extractions**: Government ID [Document](https://docs.withpersona.com/api-reference/documents/retrieve-a-government-id-document#response.body.data.attributes.native-name-first) and [Verification](https://docs.withpersona.com/api-reference/verifications/retrieve-a-verification#response.body.data.Government-ID-Verification.attributes.native-name-first) 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](https://docs.withpersona.com/response-body#specify-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](https://docs.withpersona.com/api-key-inflection) and the [Fields integration guide](https://docs.withpersona.com/integration-guide-understanding-a-persona-api-payload#fields) for reference.

* 🍃 **Sparse fieldset improvements:**
  Two improvements now apply to how [sparse fieldsets](https://docs.withpersona.com/response-body#specify-attributes) 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](https://docs.withpersona.com/api-reference/cases/set-status-for-a-case) 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](https://docs.withpersona.com/api-reference/workflows/create-a-workflow-run) 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.