Twitter POST lists/destroy.json request always gives me a 404

bug
lists
api

#1

I can’t get the lists/destroy request to work. I’ve tried most combinations I can think of, but I keep getting a 404. I’ve verified that the owner_screen_name and slug I’m using are the right ones. I’ve also tried using list_id, but it seems like list_id doesn’t work (I get an error saying I need to have list ID or owner and slug when I try using it). Every other request I make to the api is working using the same owner_screen_name and slug, so I don’t know why this one would be failing.


#2

That’s really odd. I’ve just tried creating and deleting a list using twurl and I’m unable to reproduce a 404 error, although I can produce a 112 error "You must specify either a list ID or a slug and owner." if I enter the wrong parameters.

twurl -X POST "/1.1/lists/destroy.json?owner_screen_name=evilpiper&slug=somelist"

and

twurl -X POST "/1.1/lists/destroy.json?list_id=806106504126492672"

both worked for me (assuming the lists exist and you are the owner)


#3

Hey, so I’m using oauth.io to handle my interactions with the twitter api, so it could be how they’re encoding the uri before sending. When I inspect the network traffic the request going out looks like this https://oauth.io/request/twitter/%2F1.1%2Flists%2Fdestroy.json%3Fowner_screen_name%<my_screen_name>%26slug%3D<my_list_slug> If the uri encoding was the problem, I’d expect all my other requests to be failing as well (the actual error message is {code: 34, message: "Sorry, that page does not exist."}). I’ve also validated that the list exists by going to my account and checking. Here’s the code snippet I’m expecting to work but doesn’t

 var url =  '/1.1/lists/destroy.json?owner_screen_name=' +
 userCred.screen_name +
 '&slug=' + result.slug;
 oauthFactory.twitterConnect().then(function(authResult) {
   authResult.post(url).then(function(result) {
     deferred.resolve(result)
   })
})

I got the owner_screen_name from the /1.1/account/verify_credentials.json api call, and the list slug from
```’/1.1/lists/list.json?screen_name=’ + screen_name + ‘&reverse=true’```` api call. I’m using the same oauthFactory calls for all of the requests.

Can you let me know if anything I’m doing seems off?
Thanks for the help so far!


#4

I’ve not used oauth.io - but if that request is legitimate, then url decoding the API endpoint appears to result in this:

%2F1.1%2Flists%2Fdestroy.json%3Fowner_screen_name%<my_screen_name>%26slug%3D<my_list_slug>

->

/1.1/lists/destroy.json?owner_screen_name%<my_screen_name>&slug=<my_list_slug>

That looks wrong - should be a = in the final URL (therefore should be a %3D between owner_screen_name and <my_screen_name>) - cut-and-paste error, or is that really what you are seeing?

Did you say you’d tried the list_id method as well? One parameter fewer to worry about…


#5

Yeah, that was a typo when I was replacing my actual screen name with that placeholder…it is %3D in the actual request.


#6

OK, so that’s not it… weird. Same 404 result with the list_id?


#7

list_id never works for me on any api call, I always have to use owner_screen_name and slug for some reason. I actually figured out a different way of solving my problem. I decided to just create a list that’s my webapps’ name, and remove and add members to that list (rather than creating and destroying lists which was my original design). It’s just weird that the only request that doesn’t work for me is this one (and I’m using like 5 or 6 different api calls, both POST and GET).

Thanks for all the help. If it’s working for you then it must just be something weird happening on my end.


#8

Hey, so I figured out why my lists/destroy was failing.

I needed to remove all the members from the list before being able to destroy it. The destroy worked on an empty list.

I think you guys should update the documentation to let people know, since I didn’t see it anywhere…I was using this page https://dev.twitter.com/rest/reference/post/lists/destroy

If this is intentional behavior, then the error response message should let you know that you can only delete lists that don’t have any users in them.

Thanks again for your help.


#9

Good feedback. I’ve never dealt with this myself.
I will look into it and check if this is the expected behaviour.