Started getting error 99 when requesting auth token (SOLVED)


Code that has been working for years suddenly stopped working.

Getting error 99 when requesting token. I have tried resetting the consumer keys and re-encoding base64.

I have tried with both my clients twitter account and my own. same result.

Here is the curl command I’m using to test with.

curl --request ‘POST’ ‘’ --header ‘Authorization: Basic BASE64TOKENREDACTED’ --header ‘Content-Type: application/x-www-form-urlencoded;charset=UTF-8’ --data “grant_type=client_credentials” --verbose

Here is the response minus the auth key

* Hostname was NOT found in DNS cache
*   Trying
* Connected to ( port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
* 	 subject: C=US; ST=California; L=San Francisco; O=Twitter, Inc.; OU=Twitter Security;
* 	 start date: 2016-06-29 00:00:00 GMT
* 	 expire date: 2019-09-19 12:00:00 GMT
* 	 subjectAltName: matched
* 	 issuer: C=US; O=DigiCert Inc;; CN=DigiCert SHA2 High Assurance Server CA
* 	 SSL certificate verify ok.
> POST /oauth2/token HTTP/1.1
> User-Agent: curl/7.35.0
> Host:
> Accept: */*
> Authorization: Basic REDACTED
> Content-Type: application/x-www-form-urlencoded;charset=UTF-8
> Content-Length: 29
* upload completely sent off: 29 out of 29 bytes
< HTTP/1.1 403 Forbidden
< cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
< content-disposition: attachment; filename=json.json
< content-length: 105
< content-type: application/json;charset=utf-8
< date: Tue, 20 Jun 2017 14:03:55 GMT
< expires: Tue, 31 Mar 1981 05:00:00 GMT
< last-modified: Tue, 20 Jun 2017 14:03:55 GMT
< ml: A
< pragma: no-cache
* Server tsa_b is not blacklisted
< server: tsa_b
< set-cookie: guest_id=v1%3A149796743591513829;; Path=/; Expires=Thu, 20-Jun-2019 14:03:55 UTC
< status: 403 Forbidden
< strict-transport-security: max-age=631138519
< x-connection-hash: 3706ca00297b9cf490e60923291b72d4
< x-content-type-options: nosniff
< x-frame-options: DENY
< x-response-time: 9
< x-transaction: 008a4ed900e99044
< x-tsa-request-body-time: 1
< x-twitter-response-tags: BouncerCompliant
< x-ua-compatible: IE=edge,chrome=1
< x-xss-protection: 1; mode=block
* Connection #0 to host left intact
{"errors":[{"code":99,"message":"Unable to verify your credentials","label":"authenticity_token_error"}]}

I am at a loss as to what the problem could be, the code has not changed and has been working for years.

Any Ideas would be appreciated.


That’s really odd - I’m unable to reproduce this myself. I’ve tested using an app of my own and a similar curl request, as well as this simple PHP example, and there don’t appear to be any issues on this side. I did trigger that error when I inadvertently miscalculated the Base64 encoded version of the consumer key:consumer secret pair a couple of times.

Is there any chance you’ve had any clock drift?


This sample works for me right now.


Hi Andy,

Used the example you provided and it worked for me too.

Was using an online base_64 encoder to generate the token and it seems that it produces vastly different results to the PHP base64_encode. When I plugged in the output of the php base64 encode everything came back to life.

Thanks for pointing me in the right direction.