Using a date with ISO 8601 format as start_time or end_time results in "UNAUTHORIZED_ACCESS" error

[Tianape]

GET request resulting in 200 response:

https://ads-api.twitter.com/1/stats/accounts/[ACCOUNT_ID]?entity=CAMPAIGN&entity_ids=[CAMPAIGN_ID]&start_time=2016-06-01&end_time=2016-06-08&granularity=DAY&placement=ALL_ON_TWITTER&metric_groups=ENGAGEMENT

GET request resulting in 401 UNAUTHORIZED_ACCESS error:

https://ads-api.twitter.com/1/stats/accounts/[ACCOUNT_ID]?entity=CAMPAIGN&entity_ids=[CAMPAIGN_ID]&start_time=2016-06-01T00:00:00Z&end_time=2016-06-08T00:00:00Z&granularity=DAY&placement=ALL_ON_TWITTER&metric_groups=ENGAGEMENT

The only difference between the two is that in the second one I’m using the timestamp as defined in the documentation (ISO 8601: https://dev.twitter.com/ads/reference/1/get/stats/accounts/%3Aaccount_id). But, unexpectedly that request returns:

code: 'UNAUTHORIZED_ACCESS',
message: 'This request is not properly authenticated'

Updating just the timestamps so they no longer include the time part (so they are formatted like this: YYYY-MM-DD), does result in a 200 response though.

I would expect an invalid date format error of some sorts, not unauthorized access.

[hector_borras]

Hi @Tianape,

Maybe is the library you’re using. In TWURL you should provide dates with ISO 8601.

Anyway, you get UNAUTHORIZED_ACCESS because your request is not well encoded.

[Tianape]

Thanks for your answer @hector_borras!
Still a bit of an odd error to return in this case perhaps, because the request is in fact authenticated…

I know the dates should be according ISO 8601, that’s why I thought it was odd that once I update the dates to that standard, it starts complaining. The request I mentioned is copied from the response from Twitter as being what I sent to them, but I don’t see anything wrong with it and differing from the first request (other than the ISO 8601 formatted dates).

Ah well, I’ll just use the first format for now, as that seems to at least return successfully.
I did just find that the response of the successful request does not contain any data while there was in fact data for the campaign in the date range, but I’ll create a separate forum post for that.

[hector_borras]

@Tianape, thanks for your clarification.

You’re right, but is something that is in Twitter’s hands, they decided to define that, if something is wrong coding you’re request, you will get an unauthorized_request. I think the real explanation is: If you send an URL with PARAMS, but those params are wrong coded (as dates you said) they encoded it with the oauth, and after that, when they decode that request maybe get something strange, and that’s the reason you get unauthorized, I don’t really know it. Is only a guess.

On the other hand, which library are you using? I’m quite sure that’s the reason. 'Cause, how do they know your time offset if you don’t provide it as an ISO 8601?

In my case we work with “YYYY-MM-DD” in my side, but when we make a request to twitter we transform that date into an standard.

Hope this help you
Regards!