---
title: IDV Bridge On-Premise Changelog
description: Details of IDV Bridge On-Premise (PingOne Recognize Agent) releases.
component: recognize
page_id: recognize:idv-bridge:idv-bridge-on-premise-changelog
canonical_url: https://docs.pingidentity.com/recognize/idv-bridge/idv-bridge-on-premise-changelog.html
llms_txt: https://docs.pingidentity.com/recognize/llms.txt
docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md
section_ids:
  v3-4: v3.4
  v3-3-1: v3.3.1
  v3-3-0: v3.3.0
  v3-2-0: v3.2.0
  v3-1-0: v3.1.0
  v3-0-0: v3.0.0
  highlights: Highlights
  memory-management: Memory management
  breaking-changes: Breaking changes
  v2-x-x: v2.x.x
  breaking-changes-and-deprecations: Breaking changes and deprecations
  migration-from-enrollment-data-to-v1offline-enrollment: Migration from /enrollment-data to /v1/offline-enrollment
---

# IDV Bridge On-Premise Changelog

## v3.4

* **Bug fix:** `KL_BIOM_ERROR_FILTER_TRIGGERED` \[422] is now correctly returned in all cases where the image fails our image quality checks. Previously there were occurrences where `KL_BIOM_ERROR_BAD_INPUT` \[500] was returned.

## v3.3.1

* Minor bug fixes.

## v3.3.0

* The biometric library uses an improved face detector, which should improve successful enrollment rates for customers.

* The default value for `MAX_CONCURENCY` is now aware of CPU limits placed on the Docker container instead of using just the number of CPUs, which should improve both performance and stability.

## v3.2.0

* Updated to the latest biometric library.

* This includes the removal of `filter_face_has_mask`, which is now redundant.

## v3.1.0

* **Added support for device type and origin** - To improve performance metric insights and functionality (whether a device can be safely removed), we are adding `deviceType` and `deviceOrigin` across the PingOne Recognize infrastructure, including IDV Bridge On-Premise in online enrollment mode.

* This type of insight will also be visible in the dashboard soon (Q3 '25).

```yaml
deviceType:
  - "SDK"
  - "BACKUP"
  - "TEMPORARY_STATE"
deviceOrigin:
  - "ANDROID"
  - "IOS"
  - "KEYLESS_AGENT"
  - "WEB"
```

## v3.0.0

### Highlights

* **Performance** - New memory management system reduces memory leaks and the need for auto-resets.

* **Audibility** - Full JSON logs are now available without non-JSON print statements.

* **Security** - PingOne Recognize can now run in both root and non-root configurations. In addition, we reduced the Docker image size and completed a fresh round of vulnerability scans.

### Memory management

The new memory management system allows integrators to specify how many biometric sessions can run in parallel. This effectively limits maximum memory usage. Where previous versions needed 6GB of memory, this version requires only 1GB for the same throughput. Estimated performance and throughput are summarized in [How to run PingOne Recognize Agent](idv-bridge-run-p1rcognize-agent.html), though actual performance varies depending on the customer's hardware.

### Breaking changes

* The deprecated endpoint `/enrollment-data` has been removed.

* Due to the new memory management system, integrators on 2.x.x need to make a small configuration change outlined in [How to run PingOne Recognize Agent](idv-bridge-run-p1rcognize-agent.html).

***

## v2.x.x

### Breaking changes and deprecations

The original offline enrollment endpoint (`/enrollment-data`) is now deprecated and will be removed. Most of its API remains the same except error reporting. Since IDV Bridge On-Premise now uses a new biometric SDK, error names have changed completely.

Integrators are advised to switch to the new endpoint (`/v1/offline-enrollment`) as soon as possible, or evaluate whether online enrollment better suits their use case.

### Migration from `/enrollment-data` to `/v1/offline-enrollment`

With the new endpoint, the integrator must choose a scenario (using the `Scenario` header). Scenario is similar to the `config` query parameter in the old endpoint.

* `SELFIE` scenario is similar to `config=default` in the old endpoint. This is also the default on the old endpoint.

* `TRUSTED_SOURCE` scenario is similar to `config=less-strict` in the old endpoint.

* `DOCUMENT` scenario has no equivalent in the old endpoint.

Final notes:

* The request body is the same.

* The response now follows camelCase naming conventions and the `stats` field has been removed.

* The error response is now more detailed and follows the same naming convention as the rest of the API.