Start and end time format for synchronous statistic

[Nennad]

For thhe synchronous call on GET /1/stats/accounts/:account_id

with params:

entity:CAMPAIGN
entity_ids:4poyq
start_time:2016-02-01T00:00:00Z
end_time:2016-02-02T00:00:00Z
placement:ALL_ON_TWITTER
metric_groups:ENGAGEMENT,WEB_CONVERSION,MOBILE_CONVERSION,MEDIA,VIDEO,LIFE_TIME_VALUE_MOBILE_CONVERSION,BILLING
granularity:DAY

I get response “This request is not properly authenticated”

If i use dates only,

start_time:2016-02-01
end_time:2016-02-02

it returns the results. Documentation on that page states that required format is ISO 8601, in which case the first call should work

[majoritasdev]

Hi @Nennad! Can you please post the raw request you’re making? Meaning the full request url, with the parameters.

[Nennad]

@majoritasdev it goes through my proxy which does not modify the call significantly, it does auth and pass the call
GET https://localhost/api/twitter/7/ads_ep/stats/accounts/18ce53wamhe?entity=CAMPAIGN&entity_ids=4poyq&start_time=2016-02-01T00:00:00Z&end_time=2016-02-02T00:00:00Z&placement=ALL_ON_TWITTER&metric_groups=ENGAGEMENT,WEB_CONVERSION,MOBILE_CONVERSION,MEDIA,VIDEO,LIFE_TIME_VALUE_MOBILE_CONVERSION,BILLING&granularity=DAY

[majoritasdev]

Well, I meant the full twitter request url, not your local url.

[majoritasdev]

I remember that I had this problem too. The dates were being encoded and the colons did not appear as is - but I don’t remember for sure if this was the problem.
So it would be helpful if you could provide the twitter request url along with the parameters, as they are just before sending them to twitter.

[Nennad]

@majoritasdev Thanks for the clues, I don’t have access to the actual call that my backend make handy.

I also remember i was using encoding that string but now if I try that Twitter returns something like “expected time, got [string it could not parse]”.

I am just curious if this is known issue.

As I don’t need segmentation by hour (for now) I can transform my request to have only time, not the date.

[JBabichJapan]

Generally we would advise to test the behavior of calling API with cURL or twurl because those are well tested implementations of the proxy pieces, then if you prove it works there you can spit out the raw headers with “-t” trace command and work out whatever differences are causing issues with your specific language implementation. If you do not have access to the backend, you can do something like install ruby gem or python package and run them in an interactive interpreter. Generally you should be able to pass the time as long as you match up to the correct time zone midnight for that account.

[Nennad]

@JBabichJapan Thanks, for advice and now I assume it is not (at least known) issue with Twitter and will investigate further with my backend team

[Tianape]

Hi @JBabichJapan and @Nennad,

Noticing the same behavior here. GET requests only seem to work when the start_time and end_time parameters are in YYYY-MM-DD format. I copied the request etc. to try with Postman and also twurl but got the same error: “This request is not properly authenticated”.

Parameters:

entity=CAMPAIGN
granularity=DAY
start_time=2016-06-01T00:00:00Z
end_time=2016-06-08T00:00:00Z
placement=ALL_ON_TWITTER
entity_ids=18ce53wse4d
metric_groups=ENGAGEMENT

These are the values right before they are sent to Twitter, and I checked the response to see whether they were altered in any way.
Anyway, when I change the start_time and end_time to become 2016-06-01 and 2016-06-08, the request does work. I will keep using the YYYY-MM-DD dates for now, and will continue to investigate if there’s anything I’m doing wrong, but perhaps you guys could also check and see if this is an issue on your side.

[hector_borras]

For sure you both of you use the same library!!!

[Tianape]

@JBabichJapan Getting back to this as we tried again just now but are still seeing this behavior. I tried cURL as well and as mentioned earlier this year also tried with Postman and TWURL but got the same error:

“This request is not properly authenticated”

Just like @Nennad we don’t need the hour segmentation at this moment, so we’ll continue using YYYY-MM-DD format for now, but we do want to use it in the near future. Tried in several different ways, including using Postman and TWURL, but the only difference I see while testing all of them is that there are some result headers missing when requesting in the ISO 8601 format:

'x-access-level': 'read-write',
'x-rate-limit-limit': '250',
'x-rate-limit-remaining': '249',
'x-rate-limit-reset': '1478863013'

I hope this information is useful! It’s as if the request is parsed in the API and because of the date’s format it’s not correctly formatted causing the Authorisation header not to be passed through correctly or something.

Any ideas perhaps what might be the issue?

Let me know if you need any more information!

Thanks,

Tiana