Intermittent 401 responses from API

oauth
api

#1

My company’s software is providing Twitter Ads API support for a customer that is sending a large volume of data to Twitter. Periodically we receive a HTTP 401 response from version 3 of the REST API. We are in the process to updating our software to use version 4.

As a result of receiving the 401 response, we automatically fault the endpoint - that is we prevent any further interaction with Twitter for that set of credentials until the customer updates their credentials.

This was based on this line from the Twitter docs for the Unauthorized return code:
"Missing or incorrect authentication credentials. This may also returned in other undefined circumstances."

Using our tools, I have verified that the credentials are still valid, and the customer doesn’t need to update their credentials to proceed.

My question is:
Is there something in the response where my code can differentiate between what is legitimately invalid credentials and “undefined circumstances”, so I don’t fault the endpoint?

Thanks,
Brian


#2

Hi @BrianMCzako ,

I want to confirm first that does it happen for all requests? or just randomly?
Also, could you please provide us your full request payload including URL parameter you’ve seen 401?

Is there something in the response where my code can differentiate between what is legitimately invalid credentials and “undefined circumstances”, so I don’t fault the endpoint?

I don’t think so, because it will be a security issue otherwise (potentially).
Additionally, I highly encourage you to read this post.

Especially, you may want to check carefully around encoding rules.

Best,
Shohei


#3

We saw this particular error for 27 sets of credentials for this customer, with groups
of these errors around these times, all UTC.

  • 2018-12-03 03:48:16.010
  • 2018-12-03 04:07:23.663
  • 2018-12-03 09:47:44.520

We have validated that the credentials are correct, except for 2 sets of them, and have communicated to the customer that they can resume sending data. These credentials were created at varying times between 2016 and today, so not randomly, and not likely due to the payload of the data we’re sending to Twitter.

My payload looks like the following (same as in my other post that you responded to)

[{
“operation_type”: “Update”,
“params”: {
“advertiser_account_id”: “:accountId”,
“membership_type”: “LIST_MEMBERSHIP”,
“user_identifier”: “f660ab912ec121d1b1e928a0bb4bc61b15f5ad44d5efdc4e1c92a25e99b8e44a”,
“user_identifier_type”: “EMAIL”,
“score”: 100,
“audience_names”: “:audienceName”,
“effective_at”: “2018-12-05T21:05:21Z”
}
}, {
“operation_type”: “Update”,
“params”: {
“advertiser_account_id”: “:accountId”,
“membership_type”: “LIST_MEMBERSHIP”,
“user_identifier”: “31611159e7e6ff7843ea4627745e89225fc866621cfcfdbd40871af4413747cc”,
“user_identifier_type”: “HANDLE”,
“score”: 100,
“audience_names”: “:audienceName”,
“effective_at”: “2018-12-05T21:05:21Z”
}
}, {
“operation_type”: “Update”,
“params”: {
“advertiser_account_id”: “:accountId”,
“membership_type”: “LIST_MEMBERSHIP”,
“user_identifier”: “bbaf670d8020f6e111d507df3e8a6a847a54bf3308ce4a8c7542771d2b23b094”,
“user_identifier_type”: “DEVICE_ID”,
“score”: 100,
“audience_names”: “:audienceName”,
“effective_at”: “2018-12-05T21:05:21Z”
}
}]

The only string that could have an encoding issue is the audience name, and those haven’t changed.

We only caught this recently, and I have no way of determining if this happens randomly or if it will ever happen again. I’ll add logging to our code to capture a full payload and response when it does happen.