Update of campaign start time (or end time) causes 401 UNAUTHORIZED_ACCESS error



The following PUT works just fine:

1 > PUT https://ads-api.twitter.com/0/accounts/luyeg/campaigns/4x46w?standard_delivery=true
1 > Accept: application/json

Response code of 200 and the updated value takes and is indicated properly in the returned data.

But this one doesn’t work:

1 > PUT https://ads-api.twitter.com/0/accounts/luyeg/campaigns/4x46w?start_time=2016-05-13T00:30:22Z
1 > Accept: application/json

The response I get from that one is:

1 < 401
1 < date: Wed, 11 May 2016 00:33:09 GMT
1 < server: tsa_a
1 < content-length: 122
1 < x-response-time: 9
1 < x-frame-options: SAMEORIGIN
1 < x-transaction: f7ba7c0cb4bfc287
1 < strict-transport-security: max-age=631138519
1 < set-cookie: guest_id=v1%3A146292678976791640; Domain=.twitter.com; Path=/; Expires=Fri, 11-May-2018 00:33:09 UTC
1 < x-xss-protection: 1; mode=block
1 < x-content-type-options: nosniff
1 < content-disposition: attachment; filename=json.json
1 < x-connection-hash: 9829b9702dbaba9d10af0bbafbb89fc0
1 < x-runtime: 6.1E-5
1 < content-type: application/json;charset=utf-8
1 <
{"errors":[{"code":"UNAUTHORIZED_ACCESS","message":"This request is not properly authenticated"}],"request":{"params":{}}}

Obviously the 401 would initially lead one toward an OAuth problem, but if that were the true culprit, then the first one (and many other requests that I send all of the time) should have failed also. So I’m suspecting that there is some other problem unrelated to OAuth and that the OAuth complaint is a red herring. I’ve observed similar issues with the Facebook API complaining about OAuth in a returned error message when the real problem was actually improperly formatted data parameters. In this case, though, I use that same date format upon campaign creation (POST) with no problems. The only problem arises when I simply try to update the value, using that exact same format with an update (PUT).

For simplicity, I pared down what I’m sending in the above example. In trying various things though, the pattern that I note is that the updates work fine for all update-eligible fields other than start_time and end_time. If either of those two fields is included in the update, then the 401 occurs.

Does anyone know what the real cause of such behavior might be?