API 1.8.2 Schedule Problem

I have been working with the CMS APIs from some time and find it a bit frustrating. This is on a linux platform.

fromDt and toDt require a date in the format YYYY-MM-DD HH:mm:ss but when returned will show a proper linux imestamp. However, it will not accept a linux timestamp as input. When I asked previously, I thought the answer was that it would accept an EPOCH timestamp.

When I POST a SCHEDULE to the CMS, I find that the campaignId is off by a factor of 1. I was scheduling layout ID 29 on one of my test displays, and when I checked the schedule on the console, I find that layoutId 28 was scheduled. If I POSTed layoutId 30, I would then get layout 29. Tells me that someone did not take into consideration that a PHP array starts at ZERO vice ONE

Displays: I added another test display, the console will display it, but the SCHEDULE API will not recognize it, once again a mostly useless error message was returned:
“error”: {
“message”: “Not Found”,
“code”: 404,
“data”: {
“entity”: null

Regarding date format, I believe that was already discussed in your previous topic - in code you can do it with timestamp as you can also convert that to required date format (I’ve showed you an example of that as well).

CampaignId is not off, you just need to understand that in campaignId parameter in this call you do not provide layoutId, but, campaignId.

Each layout has it’s own unique layout specific campaignId and that’s what you need to provide with post schedule call.

the very similar situation with displayGroupIds that you need to provide in this call.

each display has it’s own unique display specific displaygroupId and that’s what you need to provide in the post schedule call.

The layout specific and display specific information can be gathered by GET layout and GET display calls respectively.

Of course campaignId and displayGroupIds can also reference actual campaign and displayGroup, in which case you will want to provide their Ids, but if you want to schedule specific layout to specific display then you need to use the layout specific campaignId and display specific displayGroupId.

If it’s not clear, please do let me know.

This is not my first time through the Roundabout, been working webservices and creating APIs for abt 15 years so do have a small amount of experience.

Time - I have tried to use an EPOCH timestamp in my calls to the schedule API, however, it will not accept it, come back with the error message that it is expecting a date in set format.

Layouts - Yes, understand that each layout has an ID associated with it. In my test CMS I have about 10 created. I have no campaigns defined at this time.

I want to have a specific layout displayed on a specific display to test my software, for example layout number 29 Hotseat Winner.
In my call to Schedule I specify campaignId=29 for displayGroupIds 2.
When I go to the admin console and look at the schedule for displayGroupId 2, it shows that layout 28 Hotseat5 is scheduled.
If I go back and use 30 for the campaignId, I will then get 29 as the display. Tells me that the translation from the API call to the array does not take into consideration that PHP arrays start at ZERO and not ONE.

Displays: Yes, displays have a number associated with them. What I am saying is that I have three of them on this system. I have a call to the system and POST a layout for display 2, and will receive an eventId. I take the same call, change the displayGroupId to 3 and receive an error message “Not Found data"entity:null”.

Of course, no one has been able to tell me why the API will not accept a well-formed JSON/REST message, but insists on receiving form-data.

Perhaps it will be clearer on an example.

First of all we use the GET displays call to get to know the display specific displayGroupId (it’s not visible from the web ui and I don’t mean displayId here.)


we need the displayGroupId (11) - that’s display specific displayGroupId I meant earlier - you do not use displayId in the post schedule call!

then we call GET Layouts to get to know the layout specific campaignId


now from here we need campaignId (300), that’s the layout specific campaignId I meant earlier, you do not use layoutId in the POST schedule call!

Now, POST schedule call would be (in this example) something like:

and we can see it in the web ui on schedule page:

Does that make sense now?

PS. please click on the images to enlarge them.

A lot clearer… so essentially what is needed for the API is not displayed in the Web GUI?

I’m glad to hear that and yes, in this case.

As display specific displayGroupId and layout specific campaignId are not visible in the web ui.