Block Unblock endpoint not working

[durss]

Hello!

I have issues with the block/unblock endpoints not working or very randomly.

I’m sending proper info, I get proper 204 result, but the user isn’t blocked or unblocked.

Even worse, after blocking a user from the API, the endpoint to get all the blocked users now returns a 500.
I’ve managed to get it working back after unblocking the user from the API andpoint only. User was not listed here Twitch and using /unblock command on the the twitch chat changed nothing.
I made other block attempts after that and no the endpoint is stuck on 500. I gues i’d have to remember which users I tried to block in order to have a chance of fixing this.

The access_token is valid, every other endpoints are working properly.
I requested the proper scopes:

user:manage:blocked_users
user:read:blocked_users

It shouldn’t be a rate limit issue, i would get a 429 status code.
I tried creating a new Twitch application in case the one I used got restricted or something, but I get the exact same behavior.

TLDR : Basically, the endpoints do not work and i’m fairly convince this is an issue on Twitch’s side but I can’t tell for sure either…

Bellow is how i call the endpoints.
Block a user:
URL:
https://api.twitch.tv/helix/users/blocks?target_user_id=USER_ID&reason=REASON

Headers:

method: PUT
authorization: Bearer XXX
client-id: YYY
content-type: application/json

Unblock a user:
URL:
https://api.twitch.tv/helix/users/blocks?target_user_id=USER_ID

Headers:

method: DELETE
authorization: Bearer XXX
client-id: YYY
content-type: application/json

Get all blocked users
URL:
https://api.twitch.tv/helix/users/blocks?broadcaster_id=MY_USER_ID&first=100

Headers:

method: GET
authorization: Bearer XXX
client-id: YYY
content-type: application/json

Any idea what could be going on?

[BarryCarlyon]

The blocks stuff is often very backed up/deleayed due to “misuse” by other developers.

So it’s likely just that. People do not use these endpoints really for what they were intended to. So the system is often overloaded.

I anticipate it’s fine just “delayed” as the underlying service is busy/overloaded/not processed your request yet.

People “misuse” these endpoints to remove follows from their account for some reason and as a result the service is overloaded.

[durss]

Oh, that would be quite a terrible way of handling a service overloading if the endpoints just say “it’s fine i did what you want” (204) but actually didn’t really, and corrupts the data in the background (or something like that that’d be source of the 500)

I’m using it as well to cleanup followbot raids while the raid is happening (instead of cleaning it up after) so it’s intended to potentially do bunch of requests in a short amount of time.

Thank you for your super fast answer !

[BarryCarlyon]

@durss

I’m using it as well to cleanup followbot raids while the raid is happening (instead of cleaning it up after) so it’s intended to potentially do bunch of requests in a short amount of time.

Don’t

Thats likely the issue, if you are “spamming” a block/unblock to remove a follow. It’s getting wedged in the backend due to too many people doing this same thing for no reason

See also: the official advice for dealing with this sort of “attack”:

Hey there! Looks like you found us on a quest for help with view/follow bots. You’re in luck. While we can’t help you directly, you will find your answers here: Twitch Help Portal or here: Twitch Safety Center

There is no need to do this sort of clean up on your own. And just stops people using the block system legitimetely

[durss]

I understand that it might not be the intended way of using this endpoint but isn’t the rate-limit here to answer this kind of issue ?
I mean, if there really was too many requests done with those endpoints putting the service health at risk, I guess we would get a 429, not a 204 that says all is good when it’s not(?)

So far i have not made anything in batch so I would be surprised it would be a spam issue.
I even created a fresh new app so if there was a quota issue before, there shouldn’t be any on the new app.

[BarryCarlyon]

@durss

I understand that it might not be the intended way of using this endpoint but isn’t the rate-limit here to answer this kind of issue ?
I mean, if there really was too many requests done with those endpoints putting the service health at risk, I guess we would get a 429, not a 204 that says all is good when it’s not(?)

Your request was accepted for processing. Hence the 200.

So the backend service will get to it in time.

@durss

So far i have not made anything in batch so I would be surprised it would be a spam issue.

It’s not you making calls thats the issue.

It’s the thousands of people trying to do the same thing via other/existings tools for no reason since this isn’t the intended use case for the endpoint(s)

@durss

I even created a fresh new app so if there was a quota issue before, there shouldn’t be any on the new app.

There isn’t “per app” quota here.

It’s the flood of block/unblocks into the block service from everyone together that is the issue.