Skip to main content
Back to Kantata.com Blog Tour Status

Recommended Actions for API Changes

By Grace Kamau | Updated

This article lists breaking API changes and provides guidance for how to handle the updates. Breaking changes are API updates that could cause client applications (such as custom integrations) to fail. Although we try to avoid making breaking changes, they are sometimes necessary in order to address critical issues, align API features with ongoing product changes, or improve API performance.

Before a breaking API change is made, affected customers will be notified in advance. Information about the breaking change will also be added to this article. If you have any questions, please reach out to Customer Success or Kantata Support.

For a full list of API changes, including non-breaking changes, please see the Kantata OX Release Notes.

All Requests Must be Compliant with RFC 7230 Standard — November 30, 2025

To increase the security of Kantata, API requests will be required to meet the RFC 7230 standard for HTTP requests. The following configurations will no longer be allowed after the end of November 2025:

  • A header that:

    • Contains a non-ASCII character.
    • Contains a control character.
    • Is empty or contains a line with only spaces.
    • Can be normalized to Transfer-Encoding or Content-Length using common text normalization techniques.

  • A GET or HEAD request that:

    • Contains a Content-Length header.
    • Contains a Content-Length header with a value of 0 for a GET or HEAD request.
    • Contains a Transfer-Encoding header.

  • A request that:

    • Contains both a Transfer-Encoding header and a Content-Length header.

    • Contains multiple Content-Length headers with the same value.

  • A request version that contains a bad value.

  • A request URI that:
    • Contains control characters.
    • Contains a space that is not URL encoded.

Recommended Action

Review your HTTP requests and ensure they are not configured in any of the ways outlined above. Non-compliant requests will be blocked, resulting in errors in your custom integrations or apps.

Deprecation of Proofing APIs — December 31, 2024

After December 31, 2024, Proofing will no longer be available in Kantata OX and the Proofing APIs will be unavailable. No action is required.

 

Deprecation of subject_changed_* filters and order options for Subscribed Events API — June 11, 2024

After June 11, 2024, the following options will be deprecated for the GET /api/v1/subscribed_events endpoint:

  • The subject_changed_after and subject_changed_before request parameters
  • The subject_changed_at:asc and subject_changed_at:desc options for the order request parameter

Recommended Action

If you have a custom integration that relies on these filters or order options, the following can be used instead:

  • The created_after and created_before filters
  • The created_at:asc and created_at:desc order options

 

Acceptable date format changing to ISO 8601 for all date and date-time request fields — Starting October 2023

All date and date-time request fields will be standardized to accept only ISO 8601 formatted dates (e.g. 2023-11-18, 2023-11-18T12:34:29-06:00, etc.).

The timeline for this change is as follows:

  • Starting October 2023, all new accounts must use ISO 8601 format.
  • Existing accounts have a 9 month period to transition to ISO 8601 format.
  • By September 2024, all accounts must use ISO 8601 format.


Examples of date formats that will not be accepted after the change:

Invalid Date Format Reason Valid Date Format
2023-00-01 Invalid month. 2023-01-01
2023-12-31T235959 Missing colons in time. 2023-12-31T23:59:59
2023-08-24T17:12:00ZZ Double Z. 2023-08-24T17:12:00Z
2023-08-24 21:18:10 Missing T between date and time. 2023-08-24T21:18:10
2023-08-24 21:27:25 UTC UTC is not a valid time zone offset. Use Z instead. 2023-08-24T21:27:25Z
2023-08-24T14:32:16-0700 Time zone offset should be colon-separated. 2023-08-24T14:32:16-07:00
2023-08-24T20-41-02 Datetime should be colon-separated. 2023-08-24T20:41:02
2023-7-25 21:30:24 Month should be double digits. 2023-07-25T21:30:24
2023-08-24T21:33:23.983?page=1 Extraneous trailing content after timestamp. 2023-08-24T21:33:23.983
07/31/2023 12:47 PM AM/PM is not supported in ISO 8601. 2023-07-31T12:47:00


Recommended Action

Review your logic and update all date and date-time request fields to ISO 8601 format.

 

Temporary deprecation of time_administration_candidates filter for GET api/v1/users - March 21, 2023

On March 21, 2023, the time_administration_candidates filter for the GET api/v1/users endpoint will be temporarily deprecated. We are temporarily deprecating this filter to improve its performance.

Recommended Action

If you are using this filter, please update your logic and remove any usage of the filter. The behavior of the deprecated filter is not guaranteed during the deprecation period. The results of this filter can be recreated by using the GET api/v1/timesheet_submissions endpoint with filters, including setting the query parameter include=user .

 

Date format change for date properties in custom field value Subscribed Events — July 5, 2022

On July 5, 2022, the date format of several date properties within custom field value Subscribed Events will be changed to the ISO 8601 standard (e.g. "2022-05-18T12:34:29-06:00").

The following date properties will be affected:

  • The created_at property which appears within current_payload and previous_payload
  • The updated_at property which appears within current_payload and previous_payload
  • The value property which appears within custom_field_values for Date custom fields

The following event types will be affected:

  • estimate:custom_field_value_created
  • estimate:custom_field_value_deleted
  • estimate:custom_field_value_updated
  • estimate_scenario_resource:custom_field_value_created
  • estimate_scenario_resource:custom_field_value_deleted
  • estimate_scenario_resource:custom_field_value_updated
  • workspace_group:custom_field_value_created
  • workspace_group:custom_field_value_deleted
  • workspace_group:custom_field_value_updated
  • workspace:custom_field_value_created
  • workspace:custom_field_value_deleted
  • workspace:custom_field_value_updated
  • workspace_resource:custom_field_value_created
  • workspace_resource:custom_field_value_deleted
  • workspace_resource:custom_field_value_updated
  • story:custom_field_value_created
  • story:custom_field_value_deleted
  • story:custom_field_value_updated
  • user:custom_field_value_created
  • user:custom_field_value_deleted
  • user:custom_field_value_updated

Recommended Action

If you are parsing any of the affected date properties, please update your logic to parse dates in the ISO 8601 format instead.

 

user_can_edit removed from default response of GET api/v1/time_entries and GET api/v1/expenses — February 14, 2022

After February 14, 2022, the user_can_edit field will no longer be included in the responses of the GET api/v1/time_entries and GET api/v1/expenses endpoints by default. We are making this change to improve the performance of these endpoints.

The user_can_edit field indicates whether the current user can edit a time entry or expense. This is a value that Kantata OX does not display in the UI, nor surface in any of our pre-packaged integrations. However, as a Kantata OX API consumer, you may have asked for this value in a custom integration that you created.

Recommended Action

If you have a custom integration that relies on the user_can_edit field, please check the following:

  1. Do you parse the user_can_edit JSON? If you are not currently parsing that field, you don’t have to do anything.
  2. If you are parsing the user_can_edit JSON, you have two options:
    • If you are not using the value anywhere else in your code, stop parsing that field.
    • Add the following parameter to any GET request made to either api/v1/time_entries or api/v1/expenses: optional_fields=user_can_edit.

Related Articles

By Grace Kamau
Join us at Kantata!
Return to top