You can now use the name attribute in your update_board mutation, to change the name of a board.

An example of this would be:

mutation {
  update_board(board_id: 1234567890, board_attribute: name, new_value: "New board name")
}

Later this year, we will be adding new limits to the root Items query:

• The ids argument is now required
• You cannot return more than 100 items per query

This change will go into effect on Sunday, October 3rd, so please review your applications' API usage to prevent any loss of functionality.

We recently added a rate limit to this use case, so you may have already adjusted your code to account for this!

We will remove references to this feature in our docs, but if you spot a mention that we missed shoot us a message at [email protected].

Examples of unsupported queries

Queries without the ids argument:

query {
  items (limit:1000) {
    id
    name
  }
}

Queries with more than 100 IDs:

query {
  items (ids:[1, 2, 3, 4, 5...99, 100, 101, 102]) {
    id
    name
  }
}

How should I respond to this change?

You can adjust your queries in these main ways:

• Return items on a specific board only
• Nesting the items query inside Boards
• Looping through the boards on your account
• Query less than 100 items at a time

Return items on a specific board

You can return items only on a specific board, by ID. Here's an example:

query {
  boards (ids:12345) {
    id
    name
    items (limit:100) {
      id
      name
    }
  }
}

Nesting the items query inside Boards

Queries without Items in the root will still work, so you can nest the items query within a boards query. Here's an example:

query { 
  boards (limit:10) { 
    items (limit:1000) { 
      id 
      name 
    } 
  } 
}

Looping through the boards on your account

If you are looking to return all items across your account, it is best practice to first query for the IDs of all the boards, and then get items a few boards at a time. For example:

First, query for the IDs of all the boards.

query { 
  boards (limit:50) { 
    id
  } 
}

Second, query and loop through each board in the first query.

query { 
   boards (ids: 1234567890) { 
     items (limit:50) { 
       name 
       id 
     } 
   } 
 }

Return less than 100 items at a time

Finally, you can continue to use the same query but restrict the query to a list of item IDs. Here's an example:

query {
  items (ids: [1, 2, 3, 4, 5... 99]) {
    name
		column_values {
			id
			value
		}
	}
}

We have increased the complexity for the base “users” query by 10x, to better align with the load this operation does on our servers.

For example, this query will now cost 10,010 complexity points, instead of 1010:

query {
  complexity {
    query
  }
  users {
    id
  }
}

We have begun deprecating the [myaccountslug].monday.com/v2 endpoint, which is used by a very small number of applications in our ecosystem.

The correct endpoint to use is https://api.monday.com/v2

If your apps made any calls to this endpoint in the last 30 days, it will still work for you until May 15th. After this date, your API calls will return an error. Please update your apps to use the correct endpoint ASAP.

We have removed references to this endpoint in our docs. But if you spot a mention that we missed, shoot us a message at [email protected]!

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.