Direct messages authentication not working after api change - Direct Message Migration


As per the documentation there is a migration which is under progress for direct messages api.
I have changed the authentication based on the documentation.
Basically I did 3 changes.

  1. Changed the way we are sending data, it is json payload with recepient id.
    {"event": {"type": "message_create", "message_create": {"target": {"recipient_id": "154810374"}, "message_data": {"text": "Hello World!"}}}}
  2. Header (Content-Type) is changed to application/json
  3. Authorization details as below

Note: I am not giving timestamp/nounce but it is getting generated by postman, tried generating somewhere else and passed it but still no luck.

From apex (salesforce language similar to java) and even from postman I am getting the same error as below:

    "errors": [
            "code": 32,
            "message": "Could not authenticate you."

Also looks like api authentication is not updated, it is still using the old way of authentication.

Please let me know if there is anything which I am missing.


Thanks for writing in!

There are usually a couple of things that trigger this error:

  1. The generated tokens (nonce, timestamp, signature) are not being handled properly.
  2. There is an issue with your Twitter app tokens.

Are you handling your own oauth_signature in this call? You might want to let Postman handle that as well if possible.
I mention this because I typically have Insomnia handle my signature.

We are actively working to revise the authentication section, but to my knowledge, that specific page should still be accurate.


Hi LeBraat,

Thanks for responding, I am still facing issue.

  1. I tried resetting all the tokens by regenerating from app. No success.
  2. I am letting postman handle nonce, timestamp and signature.
  3. Looks like now I have to work from developer account of twitter, I have requested it now, once I get one then I will create the new app and will give it a try.
    I am hoping that something useful should come up.

By any chance do you have a sample postman export which is working? Or any more information on this issue.

Kiran Machhewar


Hello, smachhewar, I have the same problem… I share my CURL I am letting the timestamp, nonce and signature be generated by the postman but still nothing…

have you been able to make it work friend?


Using with postman plugin, with this configuration:

Authorization: type Oauth 1.0, consumer key, consumer secret, token, and token secret with the values corresponding to the app, signature hmac-sha1, version 1.0
Headers: content-type : application/json
body: data = {“event”: {“type”: “message_create”, “message_create”: {“target”: {“recipient_id”: “RECIPIENT_USER_ID”}, “message_data”: {“text”: “Hello World!”}}}} with valid recipient_id


    "errors": [
            "code": 215,
            "message": "Bad Authentication data."

If we add “add params to header”, the error changes to:
“415 unsupported media type”

cache-control →no-cache, no-store, must-revalidate, pre-check=0, post-check=0
content-length →0
content-security-policy →default-src ‘self’; connect-src ‘self’; font-src ‘self’ data:; frame-src ‘self’; frame-ancestors ‘self’; img-src ‘self’ data:; media-src ‘self’; object-src ‘none’; script-src ‘self’; style-src ‘self’; report-uri;
content-type →text/html;charset=utf-8
date →Tue, 25 Sep 2018 22:55:14 GMT
expires →Tue, 31 Mar 1981 05:00:00 GMT
last-modified →Tue, 25 Sep 2018 22:55:14 GMT
pragma →no-cache
server →tsa_d
status →415, 415 Unsupported Media Type
strict-transport-security →max-age=631138519
x-access-level →read-write-directmessages
x-connection-hash →
x-content-type-options →nosniff
x-frame-options →SAMEORIGIN
x-response-time →143
x-transaction →00a7708800eda85e
x-tsa-request-body-time →0
x-twitter-response-tags →BouncerCompliant
x-xss-protection →1; mode=block; report=

Missing to configure something? Via backend of our system, the migration is not working, so we try to find the problem manually first. Thanks


Postman’s implementation of OAuth 1.0 does not allow you to specify the proper oauth_token value as a URL param in the final request to the POST oauth/access_token endpoint. You need to be able to add both the oauth_token and oauth_verifier as URL params to the POST request to the oauth/access_token request for it to succeed.

I have been able to get this to work using the Insomnia app, which is very similar to Postman. I’d suggest downloading it and running through the same steps to get the user access tokens needed.