We released API version 2023-10 on July 1! It features many new and exciting updates, as well as a handful of breaking changes (read more about API versioning here).
We put together this guide (complete with a detailed explanation for each change) to help make the transition to the new version easier! Check out all of the changes below, and make sure to click on each item’s respective link to see the full details about each update
After checking out the updates, we would love to hear from you! Your opinions and feedback are vital to building, maintaining, and improving our API. Feel free to submit our feedback form or post any questions in the comments below!
Here’s what’s new
Breaking changes
Removed the deprecated items field on boards queries, replaced it with items_page
Removed the deprecated items field on groups queries, replaced it with items_page
Thank you for the headsup. As there a a number of breaking changes we need to test all our apps. I’m a little puzzled what the best way is to start testing.
is there any API versioning support in the API Playground and if so, how can we set the version? Tried to set the header in the API Playground without succes.
how do we use versioning if we do use the mondayClient from the monday-sdk-js npm packages (see below)
@basdebruin If I take a look at the monday client source here, I see you can either pass the API version in the constructor, or use the setApiVersion method after the fact.
@rachelatmonday In our case, we are using the sdk-js on the front-end without passing any token. The sdk then fallsback to sending a message to the iFrame parent:
Thanks for the solution @MaxTheBean! I am checking with the team to find a solution to your question above and will update you on this thread ASAP!
@basdebruin Thanks for the questions. We plan to also add more info about how to access the different versions in the documentation, so this is very timely. Let us know if you have any other questions while testing!
Hi @rachelatmonday,
Could you please pass on that the export of the monday-sdk-js is also not up to date with the apiVersion parameter and setApiVersion function?
@MaxTheBean and I had to dig into the source code to find out how to pass the API version because the TypeScript doesn’t declare the apiVersion parameter for the init and doesn’t export a setApiVersion function.
Adding to what Rachel posted, we would love to hear from you any feedback related to new updated API. Either bug or improvements suggestion.
Feel free to submit it in this form: Preview '2023-10' Version Feedback Form
Thank you so much! Is there an online task we can follow or have an idea of when/if changes will be done? We’d be glad to give the changes a go and provide feedback once the API version is available for front-end calls.
The devs just pushed a change today that should take care of it. Feel free to test it when you get a chance, and let us know if you have any other issues!
I can confirm the TypeScript changes are done. Thank you so much .
Looking at the code and testing it, I noticed the issue @MaxTheBean raised isn’t resolved.
For context; we call the api function of the Client in the front-end after initializing it with an apiVersion. But the api function doesn’t pass on the apiVersion parameter to the _localApi execution, which is called because we do not use tokens in the front-end.
From the source;
// From monday-sdk-js/src/client.js
api(query, options = {}) {
const params = { query, variables: options.variables };
const token = options.token || this._apiToken;
// I can confirm this is set correctly while debugging.
const apiVersion = options.apiVersion || this._apiVersion;
if (token) {
return mondayApiClient.execute(params, token, { apiVersion });
} else {
// Because we are in the front-end, we don't pass a token, so the code ends up here
return new Promise((resolve, reject) => {
// The params here do not include the apiVersion
this._localApi("api", { params })
.then(result => {
resolve(result.data);
})
.catch(err => reject(err));
});
}
}
Do you have any feedback from your Dev team about this? Ideally an estimate of when we can expect to test the new APIs?
We can specify the apiVersion in the client, but the SDK’s code requires the use of a token to actually use the apiVersion we provide (as shown in the snippet of my last post).
In our app those calls are done on the front-end and thus, we do not use tokens.
Even in the latest released version of the SDK (0.4.2) that dates from 9 hours ago, we cannot run client API calls with an apiVersion configured.
Hey @rachelatmonday
What’s the point of introducing the linked_items field when you need to specify the connected board column id and the connected board id?
You still need to run one query to get the required ids, then you can run the query to get the new linked_items array.
What I’m asking for since ages and what would reduce the API calls considerably is a way to get all the mirrored column infos in just one query.
Currently it’s a nightmare to know the (1) item id, (2) board id, (3) column id, (4) column type, (5) column text, (6) column value of mirrored columns in just one query.
Hi @rob
There are several reasons why board_id and column_id is required in linked_items:
In one linked column can be connected to 5 different boards
In one board there could be dozens of linked columns (aka Board Relation columns).
One item in one column can be connected to hundreds of items.
In the world where our boards can contain hundreds of thousands items query all linked items for single item is no longer valid options.
In fact to understand linked board id and linked column id you can run one simple query:
query {
boards(ids:1721464578){
columns(types:[board_relation]){
id
settings_str
}
}
}
which will return all linked columns with ID and linked board ids: