nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

400 error on "Schedules meetings (BETA)" with more than 2 offering types

Brian Gray

When I tested the School Meetings (BETA) endpoint with the TryIt button, I got valid results when I used one or two offering types as arguments ([1,2], [2,3], etc), but got a 400 error if I used 3 or 4 types ([1,2,3], [2,3,9], etc).

Also, the endpoint reference page should include an example of the date format required.

Find more posts tagged with

Comments

Steven Cinquegrana

@Brian Gray I've seen this too, Brian. Not sure if anything has changed in the past few days, tho.

Regarding dates, I've noticed that many of the API definitions have been changed lately to require a date-time type rather than a string. This will break any code generated from the older definitions. Just a heads up if any of your apps are still using a previous version of SKYLib•NET.

Cheers,

Steve Cinquegrana | CEO and Principal Developer | Protégé Solutions

Julian Daniel

@Brian Gray
Thank you for figuring out the maximum number of offering_types - I was completely on the wrong assumption that it didn't like 2 or 9 (activities or athletics). I guess we haven't set any times for these, because I get no results when I search for anything other than 1 or 3 (academics or advisory).

I'm thrilled that SKY is using ISO8601 dates with hyphens as separators (YYYY-MM-DD) to match timestamp date format - many other APIs are all over the map (d-m-y, m-d-y, ymd, mdy). What bugs me about the results of this endpoint is that the date and time fields are full timestamps rather than just what they say they are.:

"created_date" : "2022-08-04T12:23:46.213+00:00",
"modified_date" : "2022-08-04T12:23:46.733+00:00",
"meeting_date" : "2022-11-15T00:00:00+00:00",
"start_time" : "1900-01-01T08:20:00-08:00",
"end_time" : "1900-01-01T08:40:00-08:00",

This isn't consistent with similarly-named fields in other endpoints.

Another annoying quirk with this endpoint is that rather than page the results, it just gives up after a while - that isn't mentioned anywhere in the documentation, so if you make your date range too wide your result will just get cut off partway through a day…is that all of it? no classes after 9:30 on Tuesday? Yippee! No…the API just said “I'm tired” and gave up.

I'm hoping both of these issues get fixed, though, because this endpoint is exactly what I needed to populate our room booking calendars.