Note that the /unblock endpoint requires a POST.
If you do a GET on /unblock (e.g. by using your webbrowser to go to http://xxxxxxxxxxxxxx/api/v4/users/1402/unblock) you’ll get a 404.
Can you check the HTTP code in the response header?
This API returns true or false, and it looks like that’s not recognized by the calling app, and thus translated into a 404.
The HTTP response code is shown as Status, which is indeed a 404.
Here’s an idea:
I see that you do the API calls at an http:// address.
Is your server actually at an https:// address?
If it is, any call at http:// will get redirected by Nginx to https://.
That works fine for any GET API calls like /api/v4/users.
However, when you do a POST call, Nginx redirects it to https:// but will then issue a GET call.
As there is no GET /users/<id>/unblock endpoint, you’ll get a 404.
Tools like Postman are handy, but can hide important information, or do things automatically behind the scenes.
Using cURL with -v instead can be useful in cases like this.
Hi Palmmypoko,
Can you share your solution in this topic?
I have the same problem with unclovken users through API
Regards
Oscar
–> edit found the cause, I used PUT and had to use POST, works fine now
Below cURL command is used to block a user in GitLab using the GitLab API.
Here’s a summary of the command:
curl --location --request POST 'https://<GitLab DNS/IP>/api/v4/users/<userid>/block' \
--header 'Authorization: Bearer <TOKEN>'```
* Replace <GitLab DNS/IP> with the actual DNS or IP address of your GitLab instance.
* Replace <userid> where you wanted to block
* Replace <TOKEN> with a valid authentication token.
This command sends a POST request to the specified endpoint (/api/v4/users/<userid>/block) to block the user with ID. The authorization is handled through a Bearer token provided in the request header.