"Sorry, that page does not exist." Code 34 error

[avdw]

Hello, I’m stuck with the “Sorry, that page does not exist” error, returning a Code 34 in the middle of posting to the friendship destroy API endpoint with my (own) account.

I’m guessing this is Twitterese for “You’ve hit an account limit,” but am a little surprised, because I was only unfollowing a small batch of followers using the API (I think it was around 40 when it stopped working, and I hadn’t done much else today).

This appears to be at my account level, and not with a particular app.

How long does this last? Is it a daily limit, or did I somehow get perma-banned? Several hours later, there’s been no change in the response.

It’s confusing, because the dev docs discuss thousands of requests, but in my case it wasn’t very many. I wonder if there wasn’t a long enough pause between requests (in this very small grouping).

Note: I’ve confirmed this with a command-line client as well, so the error message in this case is false–POSTs to “/1.1/friendships/destroy.json” didn’t simply stop working, because 1) modifying the URL and trying again results in a true 404 error (and not this fakey misdirected one ;)), and 2) I can simply paste the same link into the browser and get an unauthenticated error, as expected. Despite the error, that page does exist.

[andypiper]

Following and unfollowing are account limits, not API limits. You can read more about these on the support pages. These are subject to 24 hour windows per account, subdivided into 15 minute request windows (the same as the API limits). Automated following and unfollowing is subject to the automation rules.

I’m surprised that you’re seeing that error message rather than a limiting error - I would not expect that to happen.

[avdw]

Hi Andy, thanks for the very speedy response.

I promise I’ve read everything I could find before posting, from (definitely) the docs, to SO, obscure GitHub issues from other clients/libraries, etc. Understood that this is at the account level.

I had hoped it was a 15-minute window, but no luck. As mentioned, I tried a command-line client, twurl, and pointed it at the same endpoint with a single user id:

twurl -d 'screen_name=fakename' -X POST /1.1/friendships/destroy.json

and received the same error in a JSON payload:

{"errors":[{"code":34,"message":"Sorry, that page does not exist."}]}

I thought the library I was using throttled requests to prevent such issues, but perhaps not and it triggered this response, even with a small set of requests. (As I’m assuming the real problems occur with people firing thousands of requests at the API!)

Also, a similar request with the twurl client to a different resource endpoint works fine (so it’s not the library or my account–it’s only one endpoint):

twurl -d 'id=12345' -X POST /1.1/direct_messages/destroy.json

That works, and you can see the only difference is the resource name.

Maybe it “heals” itself tomorrow, outside of 24 hours.

Incidentally, I suspect this is what occurred with a number of the issues I read for different libraries/clients on GitHub. The pattern would usually be: “P1: I’m getting this (34) error. P2: Your fault, you must be using the old API or an incorrect URL. P1 (next day): Works now! (issue gets closed)”

Or, the maintainer couldn’t reproduce and assumes it was an error by the user in constructing a request, when this same rate limiting issue (assuming that’s what it is) causes an error for one person (because they’ve hit a limit) but not another.

[andypiper]

Thanks for the research, interesting stuff and I was not aware that the API would return that error in this situation.

I suspect you may have overrun the 24 hour overall limit so things may work again after that window expires.

[avdw]

Just to restate this outside of that blob of text, after the library I was using started generating the above error, I confirmed this with twurl. For example:

twurl /1.1/account/verify_credentials.json

This returns my user info, as it should. And other requests, like the DM destroy one I mentioned above, also work. Then:

twurl -d 'screen_name=fakename' -X POST /1.1/friendships/destroy.json

Returns:

{"errors":[{"code":34,"message":"Sorry, that page does not exist."}]}

I copied/pasted that twurl request directly from the terminal, and got the endpoint itself from the docs to confirm (only changing the screen name, which was valid, and again this all worked fine for a brief while today). It’s only the one endpoint, so I think I may have triggered this inadvertently and am now stuck, for today at least…

[avdw]

It’s been more than 24 hours but this is still not working, and I’ve tried a few different things.

The API endpoint isn’t missing, because I can chop the ‘n’ off ‘json’ in my request using twurl, for example, and get a true 404 page output. Regenerated everything and still the same outcome. And other similar post commands still work:

twurl -d 'id=12345' -X POST /1.1/direct_messages/destroy.json

No problem there, and that’s the same request as above, with only a different resource name.

Same symptoms as described above. I still don’t understand what caused my account to get knocked out, if that’s what happened, as my request was only in the tens (massive fraudsters on Twitter don’t seem to share my problem ;)).

{"errors":[{"code":34,"message":"Sorry, that page does not exist."}]} is just a big fat lie.

[DanielCHood]

Are you 100% sure that you have the right screen name/user id in your request and that the friendship hasn’t already been destroyed?

[avdw]

They absolutely existed before. (They did, they did I tell you!)

But they must have done something unfortunate after I posted, because the account’s since been eliminated.

Thanks for the push in the right direction.

I still think something else was happening given the behavior I was seeing, but will slink away quietly now…

[DanielCHood]

I ran into a similar issue before. Accounts rarely get suspended from what I’ve seen but people do tend to change their screennames for some reason I’ll never understand. Any time an api endpoint gives the choice to use either id or screen name I always try to opt for id because of that.

[phocks]

I have been getting a similar error with the API attempting to turn off retweets for certain users. I obtained an array of users and was looping through them sequentially and then started getting this exact same error 34 sorry that page does not exist. I noticed that it was happening with users that had the new long user_id:

2902924802,
1409403655,
42015059,
883869877,
735414969139892200,
729408756971376600,
3024179355,
1232365934,
585147213,

So the ones that start with 7…

I tried passing the number to the twitter API as a string but that still gave me the same error. Strange to see it happening when using screen_names as well…

[andreiserbanoiu]

Made an account to leave an answer to this thing as I don’t want people to go through what I went through.

Apparently the users id and id_str fields are not the same and using the id field for new version user ids (735414969139892200 sort of long ones) gives error 34.

Using id_str instead solves the problem, but I fail to understand why there’s a difference in those fields(they have the same length) and why it isn’t explicitly written in big bold letters in the API reference.

[andypiper]

Apparently the users id and id_str fields are not the same and using the id field for new version user ids (735414969139892200 sort of long ones) gives error 34.

Using id_str instead solves the problem, but I fail to understand why there’s a difference in those fields(they have the same length) and why it isn’t explicitly written in big bold letters in the API reference.

This is clearly explained and covered in the Twitter IDs and Snowflake documentation. Thank you.

[andypiper]