Changes in API IDs internal structure (v4)

Overview

We're changing the format of Wrike's API IDs for existing customers on July 1, 2025. Please review your integrations for any validations or transformations of API IDs to ensure compatibility with the new format. Validations should match the actual limits specified below, and any transformations need to be removed.

Please note that these IDs are returned in many places, including sub-records in responses from our API and webhooks.

Don't worry, we're not changing the format or values of any IDs created before July 1. Those will stay the same, and you can continue to use them, including hardcoded ones. But any new IDs created from July 1 may be in the new format as we gradually roll out the change.

Limits

All API v4 IDs have a maximum length of 256 text characters. A text character can be one of the following:

a-z

A-Z

0-9

-

_

:

.

=

Please treat such IDs as text, and do not rely on any possible patterns in them.

Affected IDs (July 1, 2025)

The following types of API IDs will be affected:

• Task ID

• Folder ID

• Space ID

• Dependency ID

• Task blueprint ID

• Folder blueprint ID

During this update, the length of these IDs in the new format will not increase, so existing checks for ID length will continue working. However, checks for allowed or forbidden characters (see above) might be affected.

Please note that future updates may include additional types of IDs and further changes within the specified limits. We recommend reviewing your integrations for interactions with all types of IDs in advance.

What to avoid when working with API IDs

Do not use parts of it as identifiers

For example, the following code will eventually create an incorrect "entityId" (even without throwing an error) or might fail if the ID's length is less than expected:

String id = "..."; // received in a response from the Wrike API
String entityId = id.substring(2, 6); // DO NOT DO THIS

Do not change them

For example, the following code will create an incorrect "normalizedId" that can conflict with other API IDs and might not be equal to the original one:

String id = "..."; // received in a response from the Wrike API
String normalizedId = id.toLowerCase(); // DO NOT DO THIS

Do not compare them with each other except for equality

For example, the following code will result in incorrect logic, as API IDs are not guaranteed to be ordered lexicographically (or in any other way):

String id1 = "..."; // received in a response from the Wrike API
String id2 = "..."; // received in a response from the Wrike API
if (id1.compareTo(id2) > 0) { // DO NOT DO THIS 

However, code that checks them for equality is acceptable:

String id1 = "..."; // received in a response from the Wrike API
String id2 = "..."; // received in a response from the Wrike API
if (!id1.equals(id2)) {
    // Code for when IDs are not equal
}

Self-check list

What if my integration applies some transformations to API IDs?

Please review your integrations and update their code to avoid such actions with API IDs before July 1, 2025, or your integration might stop working.

What if my integration applies some limits to API IDs?

Please review your integrations and update their code to follow actual limits for API IDs before July 1, 2025, or your integration might stop working.

What if I don't migrate my integration before the deadline?

Any affected integrations that are not migrated before July 1, 2025 will stop working.

What if my integration doesn't perform any such actions with API IDs?

Then no further actions are required here. Thank you for building a reliable system!