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.
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
}
}
}
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.