Intermittent 401 responses from API

[BrianMCzako]

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

[jrsyo]

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.

Guidance for UNAUTHORIZED_ACCESS issues

Recently, there have been several forum topics around UNAUTHORIZED_ACCESS. Some examples include: Could not access Ads API with UNAUTHORIZED_ACCESS error Ads API 403 'Unauthorized Access" How to generate Authorization Header Unauthorized_access UNAUTHORIZED_ACCESS - Ads API Modify campaign via API Obtaining OAuth bearer token As this post states: If you receive a 401 UNAUTHORIZED_ACCESS, the likely cause is that your authentication credentials were missing or incorrect. We strongly recomm…

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

Best,
Shohei

[BrianMCzako]

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.

[joncipriano]

Were those accounts re-authorized with your application via 3-legged OAuth between the time of the incident and when things started working again?

Could you also re-confirm for the accounts in question, were “all” API requests failing during this time or just this audience endpoint?

There is not much insight we can derive without the actual request and response data. We have no record of any incident on the Twitter side that would have been related.

[BrianMCzako]

Jon,

The have minimal access I have to see customer information tells me that they have not re-authorized just yet.
We have received the “On January 18, 2019 , the new Sign-in with Twitter app privileges will be required” e-mail and we have a plan to reach out to our customers to perform this update.

We just don’t want to make any changes to a major integration such as Twitter prior to the holidays.
When the accounts failed, we faulted them internally, which prevents any further communication to Twitter for those accounts. So I can’t tell you whether all API requests were failing - we simply didn’t make any more requests.

However, we had our customer un-fault the accounts, and data resumed flowing to Twitter.
The only reason I ask about the “other undefined circumstances.” because that’s what is in your documentation.

Is it possible that we’re hitting throttling limits in such a way that Twitter returned this error to stop any further communication?

Thanks,
Brian

[joncipriano]

Thanks for the answer. Re-authorization issues would normally be a 403, but just wanted to check.

You would receive an explicit rate limiting error if it was a rate limiting issue.

Other defined circumstances usually has to do with the way the data is being passed or encoded. Rare edge cases that depending on your perspective may or may not have to do with authentication.

I believe your org has internal escalation points here now, so if this issue does occur again post the request/response details, let us know and we’ll investigate.

[BrianMCzako]

Thanks Jon, I think that’s reasonable.
We are beefing up logging to capture this sort of error.
You’re welcome to close the issue in the meantime. I’ll open a new one if we see it again.

Brian