Open maxullman opened 8 years ago
While I would like turbo being exposed, bringing back the delete_at field would be more useful (for me), since we use that field.
+1, delete_at is important to us
I would assume it was removed, since VODs can also be deleted earlier by the owner, so it is more like a scheduled delete at or "expires_at". Further you should be polling the broadcast endpoint, since you're supposed to refresh data every now and then (I think it now says "reasonable amount of time", but don't take that as what's actually written in the API agreement), plus polling takes manual deletion into account.
+1
I raised this concern when delete_at was initially dropped with no response from support. It was a big pain and happened to had been dropped on the same day that I released a new feature that relied on it, so I ended up using a similar workaround with +14 and +60 days.
A few months ago the delete_at field was silently removed from the past broadcast endpoint. Now as a workaround I'm taking the creation date +14 days for regular users and +60 for partners. My understanding is turbo users also have past broadcasts kept longer, so short of polling the broadcast endpoint and guessing there should be a way to see if a user is turbo (and/or the delete_at field should be reintroduced).