Set of `allow_dms_from` fails and return code 87 : Client is not permitted to perform this action


#1

Hello,

I am implementing the update of direct message settings within the Tweetinvi library for .NET developers.
I have been reading the announcement post API Updates for Direct Messages Rules and therefore concluded that I should be able to perform the following webrequest.

https://api.twitter.com/1.1/account/settings.json?allow_dms_from=anyone

When I do so, Twitter returns the code 87 and the message “Client is not permitted to perform this action”.
I have ensured that the application permissions contains both “Read, Write and Access direct messages” as mentioned in the post.

I can successfully retrieve the value of the settings form the GET endpoint, but the POST endpoint refuses to update the allow_dms_from.

Please give us more information to successfully implement this feature.

Kind Regards,
Linvi


#2

It’s actually ?allow_dms_from=all not anyone.

The original documentation is incorrect


#3

Hi,

Thanks for you replied but I already tried with all without success. I have the exact same issue.

https://api.twitter.com/1.1/account/settings.json?allow_dms_from=all

HttpResponseCode : 403
TwitterApi Code : 87
TwitterApi Description : “Client is not permitted to perform this action.”

Are you able to execute the query on your side?

Cheers,
Linvi


#5

Could the team give an answer to this question as I am waiting for you to release a new version of the library.

Thanks,
Linvi


#6

Hi @TweetinviApi, first off, thanks for giving the .NET community some love with the Twitter API.

@richardhyland is correct. It is “all.” I’ll correct that post right after this.

Regarding your current issue, you may be attempting to update settings via a GET request. While you can retrieve settings via GET, to change settings you must construct a POST request. Give that a shot and maybe that will fix your issue.

Additionally, expect some updates regarding this API feature and stay tuned to forum announcements. Thanks!


#7

@TweetinviApi, just received an update. While my last response remains true, the ability to modify the setting via the API was recently changed to whitelisted only and would explain your code 87. Refer to the updated original announcement for attaining access.

Apologies for the lack of communication here. I’ll take responsibility as I have been traveling and not checking in on this endpoint. Let me know if there is anything else I can help with.


#8

That’s really annoying that this feature has been changed to whitelisted only, especially as it’s a feature I’ve already implemented and in production!

Now to find out it doesn’t work because it’s been changed to whitelisted.


#9

@richardhyland, if this is severely affecting one of your production apps, please shoot me a DM and we’ll see if we can get this sorted out.


#10

Hi,

Thank you for this response. At least I know that this feature is not available.
Now I don’t see any real benefit in whitelisting such a feature?

To be honest I really think Twitter should stop most of its whitelisting cause it is just causing difficulty for the developers.

Many of them just uses Twitter public keys to get around this and there is no longer any point in whitelisting your endpoints. I just wanted to let you know. Maybe this could change something in the decision the team takes.

Just to conclude, should I consider this issue close, meaning this feature will never be available for developers not using your public keys?

Regards,
Linvi


#11

Hi @joncipriano

It’s not severely affecting an app, more of an annoyance. I’ve put in a whitelisting request and I’ll drop you a DM if I don’t hear anything.

Thank you for your response :smile:


#12

@richardhyland, I completely understand.

@TweetinviApi, thank you for the feedback. The criticism is welcome and this is something I will bring up in future discussions here.

While a decision to whitelist an endpoint is an inconvenience to the developer it is done in good faith to protect the user experience. I won’t detail the use case, but in this case it was absolutely necessary to ensure the endpoint was not abused. The communication should have been handled better, so thank you for bearing with us.

This endpoint will likely stay whitelisted. If an app is granted access to a whitelisted endpoint and is using your library, I would normally suggest to the implementor to update the code (or someone like myself would update the code) and submit a pull request to you. You could then trust the the modification was tested and being run in a production environment.

Likewise, if a developer is using your library and is trying to use a whitelisted endpoint, don’t hesitate to reach out to myself here or on Twitter and we can see what we can do to come up with a solution.


#13

Thanks for the info. While you are here, a quick last question, do you think ‘major’ open source libraries could make a request to have some white listed access for testing purposes? I made a request for the ADs API without receiving any answer.

I am asking because I would be keen to support the entire Twitter library (whitelisted endpoints and ads api).

Cheers,
Linvi


#14

@TweetinviApi (Linvi), that’s great question and is a thought I have been thinking about recently. I think it is a great idea to consider. I would not be able to make that decision myself, but I think the request is valid. While it couldn’t happen over night, I’ll start the conversation with my team. I’ll keep you in the loop.


#15

Thanks for everything. I think we can consider this thread as closed.


#16