The schedule (on the site as well as in the API) only lists broadcast TV shows. The whole architecture of the schedule simply doesn't allow for webchannel "binge dumps" since it's not possible to list two episodes on the same combination of network+timeslot.
On the site this isn't much of a problem because tools such as the calendar or watchlist can be used instead. In the API, the full schedule endpoint has always been an acceptable fallback, but I agree there should be an easier way to retrieve these episodes with the ever increasing prominence of web channels. Let me think about this.
e.g. /webschedule?date=2019-01-01 (all webchannel episodes on that day) and /webschedule?date=2019-01-01&country=US (episodes from US-only web channels) and /webschedule?date=2019-01-01&country= (episodes from global web channels)
2. Add a parameter to the schedule endpoint
e.g. /schedule?date-2019-01-01&country=US&web=all (broadcast US shows + all webchannel episodes) and /schedule?date-2019-01-01&country=US&web=US (broadcast US shows + US-only web channels) and /schedule?date-2019-01-01&country=US&web=global (broadcast US shows + global web channels) and /schedule?date-2019-01-01&country=none&web=US (no broadcast episodes, US-only web channels)
I lean towards the separate webschedule endpoint (#1), since #2 has confusing semantics: the country parameter defaults to "US" while the web parameter would have to default to "none" to keep behavior for existing API clients unchanged and I don't want to introduce API versioning yet at this stage. The consequence is that you'd need two requests if you want the broadcast as well as the webchannel schedule though.
Sorry for the late reply. I did not expect that somebody reply to this thread so fast (email notifications ftw).
Thanks a lot for your replies @david and @ gazza911. For me all options are ok.
But I understand gazza911's point to not break existing implementations. To prevent this an additional parameter would help. But more logical and much cleaner (in my opinion) is your 2nd option for me @david.