You can now retrieve an item’s email address via the API!

The 'items' query will now accept an 'email' field. Here is an example of a query for an item's email address:

query {
  boards (ids: 12345678) {
    items {
      id
      email
    }
  }
}

The query above will result in a response like this:

{
  "data": {
    "boards": [
      {
        "items": [
          {
            "id": "1234567899",
            "email": "[email protected]"
          }
        ]
      }
    ]
  },
  "account_id": 1234567898
}

Happy building!

You can now delete your board via the API by using the delete board mutation!

Enjoy the ease in deleting boards without the manual work of navigating the site.

The delete board mutation will allow you to delete one board at a time.

Below are examples of how to use this new mutation:

mutation {
    delete_board (board_id: 12345678) {
        id
    }
}
let query = 'mutation { delete_board (board_id: 12345678) { id }}';

fetch ("https://api.monday.com/v2", {
  method: 'post',
  headers: {
    'Content-Type': 'application/json',
    'Authorization' : 'YOUR_API_KEY_HERE'
   },
   body: JSON.stringify({
     'query' : query
   })
  })
   .then(res => res.json())
   .then(res => console.log(JSON.stringify(res, null, 2)));
curl --location --request POST 'https://api.monday.com/v2' \
--header 'Authorization: YourSuperSecretApiKey' \
--header 'Content-Type: application/json' \
--data-raw '{"query": "mutation { delete_board (board_id: 12345678) { id }}"}'

The delete board mutation is currently live and ready for use!

From October 11th, 2022, we'll be validating the JSON you send to update column values. Sending unexpected values will return an error. For example:

To update an hour column, you must send the hour and minute in 24-hour format.

"{\"hour\":16,\"minute\":42}"

If you send an unexpected value, for example:

"{\"hour\":false}"

You will see an error saying that "hour" should be a number and that the "minute" key is missing.

Validation will not only check for expected keys, but for types as well. Sending a string when an integer is expected will result in an error, for example.

How should I respond to this change?

If you are updating column values, you should confirm you are sending expected values by comparing them to our Column Types Reference here: https://api.developer.monday.com/docs/guide-to-changing-column-data

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.