3.0.0 - Major API Overhaul

April 23, 2026

ItemPath 3.0 introduces a major API overhaul, replacing the legacy backend with a newer platform foundation built to support the next generation of the product.

New Platform Foundation

ItemPath now runs on a modernized backend architecture that replaces the legacy API and lays the groundwork for future product improvements.

Guided Migration to the New Platform

Upgrading to 3.0.0.0 moves cloud deployments from the legacy Flask stack to the new backend architecture, including a managed database migration path and release-specific deployment checks.

Smoother Transition for Existing Integrations

The new API layer preserves existing route patterns for key endpoints, which helps reduce disruption to existing integrations during the transition.

Modernized Authentication and Account Flows

Core account features now run through the overhauled backend, including login, token refresh, logout, first-user setup, and password reset flows.

Performance Improvements for Data Push and Data Pull

We’ve improved how Data Push and Data Pull tasks are processed behind the scenes, helping integrations run more efficiently and reducing slowdowns caused by overlapping or overloaded background jobs.

Breaking Change: Standardized Error Response Structure

Error responses are now standardized around a top-level `detail` field. 

Impact: High. Customers who rely on specific JSON error keys from the legacy API should update their integrations to support the new structure.

New Structure:

Example client-error response:

{
  "detail": "Current Password is incorrect."
}

Example unexpected server-error response:

{
  "detail": "ItemPath has encountered an unexpected error. We've logged this issue, but feel free to reach out to support@itempath.com.",
  "error_id": "uuid-unhandled"
}

If your integration currently parses keys such as message, error, or other endpoint-specific error fields, update it to read detail instead. For unexpected server failures, integrations should also tolerate the presence of error_id for support tracing.

Compatibility Note

If your integration currently parses keys such as `message`, `error`, or other endpoint-specific error fields, it should be updated to read `detail` instead. For unexpected server failures, it should also tolerate the presence of `error_id` for support tracing.