@Ericccd I see you’ve created a separate topic with the same question, I will answer here and cover both topics as the answer is the same.
Why we’ve made this change
In previous CMS versions, once you created a layout it had assigned layoutId and that didn’t change over time.
What that means is, every time you open layout designer and make any changes to the layout, players that have this layout in active schedule will be notified. Therefore they will download the changes once they are made - which for some use cases might be suitable, for a lot of other cases that is not the desired workflow.
It was also possible to add say empty region or an invalid widget or something not set entirely correct yet, but since that’s all on one and the same layout, it would be pushed to the players.
In version 2, we have introduced Draft and Publish layout status.
Once layout is published and scheduled, that version of the layout will be sent to the players.
Now, you can enter designer, checkout the layout, which will change its status to Draft.
You can edit the draft, make any changes you wish and that in itself will not affect the players.
Players will get notified about changes only after you publish the layout, at which point they will download this new layout and display it.
In version 2.1 you will also be able to set a specific date at which the layout should be published ie
you can make changes ahead of time, then let’s say you don’t want the players to update the layout just yet, but instead you know that new content should be displayed from a specific date and you don’t necessarily want to publish it manually either, so you can do just that - set a date to publish and let the XTR take care of that for you.
Answer to your question.
Now that we have some background behind the change described, let me answer your question.
As per your other topic, you’ve discovered that the checkout call, returns the new layoutId, which you can use.
However, you can also access the draft layouts via API without calling checkout ie let’s assume you have some drafts you want to edit via API already ie you don’t want to call checkout you just want to get their layoutIds.
there are 2 parameters to consider here which you can use with the get layouts API call.
parentId - when the draft gets created it will have the original (parent) layoutId in the parentId paramter.
That will be easiest to get the layoutId you need.
publishedStatusId - 1 published, 2 draft, technically you can get an array of drafts and then exclude those with parentId null to get the actual drafts
Example
Let’s say I want to edit a draft and that I happen to know the id of it, I can call
/api/layout?layoutId=450
Alternatively, if you do not know the original layoutId, you can search by name, tag etc.
which will give me ( I won’t paste the full response here)
"layoutId": 450,
"ownerId": 1,
"campaignId": 394,
"parentId": null,
"publishedStatusId": 2,
"publishedStatus": "Draft",
[...]
I can see it’s a draft and that it has parentId null ie 450 is the layoutId you can see in web ui ie the original layout id.
Now, I can call:
/api/layout?parentId=450
which will give me ( I won’t paste the full response here)
{
"layoutId": 452,
"ownerId": 1,
"campaignId": 394,
"parentId": 450,
"publishedStatusId": 2,
"publishedStatus": "Draft",
[...]
It is a draft and the parentId is 450, as such I know the 452 is the new layoutId of the draft, once you publish the layout you will see the 452 in web ui as well.
Of course the API call should be with embed=regions,playlists,widgets
parameter, if you need the regionIds etc, but you already knew that.
I hope that helps.