Change Log

To improve and support future development, we're changing the way IDs are represented in our public Wrike API. This might affect your integrations if they apply any transformations, validations, or other checks on Wrike API IDs.

Please review your code for such cases before July 1, 2025, or your integrations might stop working.

Please refer to the Changes in API IDs Internal Structure (v4) page for more details, or contact our customer support if you need help.

We've added support for Datahub in our API.

To manipulate data in Datahub itself, see our Overview and Schema reference sections.

To manipulate the Datahub connection in Wrike (Link To Database and Mirror fields), the following Wrike API v4 parts were amended:

• Custom fields. Link To Database and Mirror fields information have been added into the settings parameters along with addMirrors and removeMirrors.
• Folders and projects. Link To Database and Mirror fields can be included into the customColumns parameter. Link To Database value can be queried and set via the customFields parameter.
• Tasks. Link To Database value can be queried and set via the customFields parameter.

All of the Wrike API v4 changes are backward compatible.

We've added support of spaces in API v4. That allows you to get list of spaces, differentiate space from folder and also create webhooks for spaces. Following updates were added:

• Get spaces list
• Get folder tree in space
• Get tasks in space
• Create webhooks for spaces

API v3 has reached its end of life and API calls are not guaranteed to work. Please migrate your v3 apps as soon as possible. We are happy to answer all questions on Developer Community.

We've added a new API that lets you view information about your account's Activity Reports in a programmatic way.

This allows for integration with security information and event management (SIEM) and cloud access security broker (CASB) systems, as well as ad-hoc analysis of users' activity.

BI Export API lets you export your account’s data for future import to third-party analytics tools (e.g. Tableau or PowerBI). The data is stored in tables, which are connected using foreign key identifiers (like in a relational database). Each table is stored as a separate .csv file.

For more details check documentation for the API and BI Export schema.

API webhooks are now out of beta and officially available and supported. Combined with various bugfixes and reliability improvements, the update also has new Webhooks features:

• 16 new events, covering various changes to folders & projects
• New event for task custom field change
• Payload signing option, which allows you to set up fully secure communication channel via webhooks
• Ability to specify list of events to subscribe
• "Recursive" webhooks, which allow you to subscribe to changes anywhere in the folder/task hierarchy by registering just one hook on parent folder

We are happy to announce immediate availability of Wrike API v4. Our flexible work management platform allows you to integrate with your existing tools and systems with Wrike. API v4 is a new generation of REST APIs that is designed for improved security and scalability. Learn more here.

The primary difference between Wrike API v4 and v3 is that the new version can only access data from one account at time, and the method URIs are changed accordingly. As such, though being very similar, API v4 and v4 are incompatible and some changes in calling code might be required. The full migration guide is available here.

In order to complete improvements for Wrike security and scalability, we will be deprecating Wrike API v3 in favour of new version. End of Life of API v3 is June 30th, 2019 and API calls are not guaranteed to work after that date. We are happy to assist with migration and will answer all questions on Developer Community.

Today we announced the release of Custom Workflows, where users are no longer confined to the four default task statuses (read all the details in this blog post). Custom Statuses and Custom Workflows operations are already available through the API:

• Get a full list of existing Workflows using [GET] /accounts/{accountId}/workflows
• Add a new Custom Workflow using [POST] /accounts/{accountId}/workflows
• Add or remove Custom Statuses from a Custom Workflow using [PUT] /workflows/{workflowId}

We have also added auth scopes related to managing Workflows (read the details on auth scopes in our docs on OAuth):

• amReadOnlyWorkflow, amReadWriteWorkflow: access to the Workflow endpoints is given only for apps that request these scopes during authorization. Access is either read-only or read/write, respectively.
• amReadOnlyWorkflow has also been added to the default auth scope, so by default users can retrieve a list of all existing Workflows in the account.

We have also updated the Custom Fields parameter returned in [GET] /accounts: now you will know the type of Custom Field and can handle data input / output correctly, whether it is a boolean value, date, or any other type of data supported in Custom Fields.

We have added auth scopes that express Wrike data user permissions. The scope is selected during the OAuth 2.0 authorization (details in our docs on OAuth). Possible values are the following:

• wsReadOnly, wsReadWrite: required for requests involving all data available to users in the Wrike workspace (tasks, folders, comments, timelogs, etc.). Access is either read-only or read/write, respectively.
• amReadOnlyInvitation, amReadWriteInvitation: invitation related requests. Access is either read-only or read/write, respectively.

If no scope is explicitly requested, we set the default scope to the API client, which is equal to wsReadWrite. This means that by default, users interacting with Wrike through the API can modify any data available to them in the Wrike accounts they have access to, except user invitations.

Here's some info about upcoming updates to the Wrike API v3.

The following updates will be released on February 19, and may affect your applications as some minor API features will be deprecated:

1. In [GET] /folders methods:

• children member will be deprecated. Instead, please use childIds, which was introduced in October 2014. Check docs

2. In /timelogs methods:

• date parameter will be deprecated. Instead, trackedDate should be used.
• date member will be deprecated. Instead, createdDate or trackedDate should be used, depending on your purpose.

These new features are being released on February 17 to help you improve your workflow:

1. [GET] /tasks methods were updated with several parameters:

• Subtasks can now be included in the search scope: e.g. /tasks?subTasks=true
• Values of custom fields and also their general availability for a task can now be included in the search scope: e.g. /tasks?customField={id: "search_id", value: "optional_search_value"}

2. [GET] /folders methods have been updated with search by permalink: e.g. /folders?permalink=...

3. Optional field briefDescription has been added to Folder model.

4. For those who are migrating their apps from APIv2 we now provide the [GET] /ids method, which can be used to convert legacy APIv2 IDs into APIv3 IDs.

Today we announced our Dynamic Platform Release and there's a long list of things we've been up to in the last couple of months (see our blog post). But the highlight of the release is Custom Fields. Now every task can contain properties you and your coworkers create according to your own needs. This feature is already reflected in the API in the following way:

• You can get a full list of Custom Fields created in your account using [GET]/accounts
• You can read and edit values of Custom Fields on specific tasks using [GET]/tasks and [PUT]/tasks

Don't forget that visibility of Custom Fields values is set on a per-user basis. Search of tasks by Custom Field names and values is on the way!

Still, Custom Fields is kind of a user interface oriented feature and of course there is some data which does not need to be visible. So we're also releasing an API-exclusive Metadata feature. Now all your Accounts, Users, Folders, and Tasks can be updated with metadata — for instance, mappings with IDs of objects in other tools and systems you use. Metadata is isolated on a per-application basis and can be accessed through methods working with aforementioned Object types. Check the full API reference for more info.

We've added a couple of limits for text fields which you change through API, here's the list:

• Task and Folder Titles - 1,000 characters
• Task description - 1,000,000 characters
• Task and Timelog Comments - 10,000 characters

We've added several new features into our API and made slight modifications to existing methods to make interactions more convenient and logical.

First of all, we now support a feature that was previously accessible only through the web-interface: task dependencies. They are mostly used on our own Timeline view (Gantt chart) but now you can make a similar representation. Dependencies are not part of a Task model but a separate entity with its own group of methods - check the Dependencies reference.

In order to facilitate folder tree traversal we've done the following:

• added childIds list to folder model
• added descendants=true/false parameter to [GET]/folders/id/folders

Also we now strictly forbid modification operations with entries which are children of deleted entries or deleted entries themselves, e.g.:

• Create/modify comment in deleted task
• Create/modify timelog in deleted task
• Add/modify attachment in deleted task
• Modify deleted task itself