Until a week ago I was using a documented route from the API helix/moderation/banned/events
This would allow me to cross-reference the unban data I receive from the EventSub event which does not indicate whether the unban is from à temporary or permanent banishment.
By querying the API, I could therefore determine this data.
For a week now the “helix/moderation/banned/events” route has returned a 404 error. The route without “events” parameter does not return the ban history, so I am no longer able to determine the information that I had before…
Do you know why this change has not been documented / notified? Do you have another way of knowing that an unban was a premature end of timeout and not a removal of banishment (other than by storing on my side the list of user ids at each ban)? This is very problematic for my tracking tools…
It is stated that the information is supposed to be the same on both routes. However, before I had the bans of the past, which allowed me to find that a ban was temporary. Now the route no longer sends data if the ban is already lifted. By the time I call the road it’s already too late.
And EventSub unban event does NOT return the information that the ban was temporary.
So there twitch tells me that he can’t give me the data he was able to give me a week ago.
And that it would therefore be up to me to store all the ban events in order to determine if an unban is important or not (It’s still not the same thing if one of our moderators deletes a timeout or deletes a definitive ban…)
You can cross reference the unban with the last action taken on the account in your reference table, then seen if it was a timeout, or a ban that was lifted.
But yes you are correct the unban eventsub and pubsub moderation actions topic just report an event occured and doesn’t reference a secondary event.
For this I use the ban and unban topics together and can see if a unabn was an early timeout removal. As my Database table stores the needed information from the two events.
If this doesn’t fit for you then you need a uservoice to ask Twitch to expand on the data
Given theres no “meta data” on a unban event (reason for example since unbans/untimeout doesn’t take reason) then you won’t know this the old way either. (and the old way using /events wasn’t super reliable, the number of times /evnets would have no events as the cache had been reset was gnarly)
From the raw data on the old or new system you don’t know if these events are “important”
Unless the moderator marks it as such in your system.
Was it a misclick, was it an unban from an appearl? You don’t know from the raw data alone as I’m not sure what conclusions you were making from the old /events/ endpoint
We have a big twitch channel and dozens of moderators. We send the definitive ban/unban information in a Discord channel. Without this information directly, we are logging into the unban channel (therefore important) of simple premature end of timeouts. This generates unnecessary verification work where before it was known that what appeared there had to be checked.
I would see on occasion to create an entire system to store each ban with the initial temporary information provided by EventSub. I know very well that what is submitted on TwitchVoice has very very little chance of being implemented or so in years…
