We have added one more limit for queries that retrieve items directly.

Queries that do not specify any item IDs, board, or group can only be made 1 time every 2 minutes. For example:

query {
   items {
      id
      name
   }
}

Queries that specify more than 100 item IDs can only be made 1 time every 2 minutes. For example:

query {
   items (ids: [1, 2, 3, ..., 101]) {
      id
      name
   }
}

These two query types share this limit. For example, if I run a query that does not specify item IDs, I will have reached the limit and I will not be able to run a query that specifies more than 100 item IDs in the same 2 minutes, and vice versa.

Today we hit a big milestone – board IDs for new boards are now larger than 2147483647. Our users are creating more boards and workflows than ever!

This also means they cannot be stored as integers. More specifically, they are too large to be stored as a 32-bit signed int.

If you are currently handling board and item IDs in your application as integers, you need to update your application to use another data type such as bigInt.

You will also need to run migrations on any databases that store board IDs as integers, as they will fail to store any new board IDs.

You can now query items and get information about the related sub-items within the same query. You can find out more about this option in the Subitems section.

We recently added the ability to query complexity in all mutations, in addition to queries.

For more information, check out our community announcement here.

We recently made a change to our API complexity limits for apps. From now on, read and write actions will be broken into 5 million buckets each.

For more information, check out our community announcement here.

You can now create dependency columns via the API, as well as update their column values. You can find more info on the values this column supports in our Column Types Reference here.

The pos field for columns has now been deprecated. If included in any column queries, the value will be returned null.

Check out our Columns page for more information.

Mirror columns can now be connected to multiple columns on different boards. Therefore, the settings_str for any mirror columns that support this functionality will have a different JSON structure.

If your app uses this data, you must support both JSON formats.

The linked columns will now be stored in the displayed_linked_columns key, instead of the displayed_column key. See below for examples:

Previous format: JSON settings for mirror columns that don't support multi-board mirroring

{
  "relation_column": {
    "link_to_item" : true
  },
  "displayed_column": {
    "timeline": true
  }
}

New format: JSON settings for mirror columns that support multi-board mirroring

{
  "relation_column":{
    "link_to_item":true
  },
  "displayed_column": {},
  "displayed_linked_columns": {
    "101339646": [
      "linked_column_id"
    ]
  }
}

To support both versions, your app should check displayed_linked_columns for a value. If the key does not exist or is blank, then use the value in displayed_column.

To learn more about multi-board mirroring, check out this article: Multi-board mirroring

We released a new field parent_item when querying items that will allow you to see parent item data when querying your subitems.

To learn more, check out our Subitems article and our community announcement,

We now support subscribing to sub-item events with Webhooks. You can use the Integration Center, as well as the API to do so.

Find out more on the Webhooks documentation page, and in this community post.