Client Events API call - oldest events first or am I not parsing correctly?

SOLVED
cmiarshvac
Getting noticed

Client Events API call - oldest events first or am I not parsing correctly?

--Updating to include actual timestamp from response--

 

I am making an API call using this structure:

 

"GET/networks/[networkId]/clients/[id_or_mac_or_IP]/events"

 

In my responses, the 'ocurredAt' is in the form:

1531233271.311001

 

I am assuming that this is an Epoch timestamp with extra precision after the '.' Based on that assumption, I  am running a timestamp conversion using only the integer before the '.'

 

When I do this, my dates are 6 months old. Am I not parsing this correctly or does the events endpoint return data oldest -> newest?  If so, is there a some parameter that will  give me newest first?  I don't see a timespan option in the API docs. 

 

As always,  all help is appreciated.

1 ACCEPTED SOLUTION
HodyCrouch
Building a reputation

The endpoint /networks/[networkId]/clients/[id_or_mac_or_ip]/events includes parameters for startingAfter and endingBefore.  The documentation warns against client applications setting these parameters.

 

When you make a request to this API, the response includes a Link header.  For example:

 

Link: <https://n000.meraki.com/api/v0/networks/N_1234567890/clients/abc12345/events?startingAfter=1476908909.0>; rel=first, <https://n000.meraki.com/api/v0/networks/N_1234567890/clients/abc12345/events?startingAfter=1517256994.237001>; rel=next, <https://n000.meraki.com/api/v0/networks/N_1234567890/clients/abc12345/events?endingBefore=1548874564.0>; rel=last

You can use the values of startingAfter or endingBefore in the Link header to work your way through all events for a given client.

 

If you want to throw caution to the wind (as I might have done), you could try adding the endingAfter parameter to your original request and including the current unix epoch.

 

Otherwise, the API seems to return the oldest events.

View solution in original post

8 REPLIES 8
HodyCrouch
Building a reputation

How are you performing the timestamp conversion?

 

When I convert 1548864847, I get Wednesday, January 30, 2019 11:14:07 AM GMT-05:00

I am using the datetime module in Python 3.7,  Here is the parse and conversion:

 

timest = (str(i.get('occurredAt')).split('.'))[0]
newtime = datetime.datetime.fromtimestamp(int(timest))

C:\Users\brecht.schamp>python
Python 3.5.4 (v3.5.4:3f56838, Aug  8 2017, 02:17:05) [MSC v.1900 64 bit (AMD64)]
 on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> timest = "1548864847"
>>> newtime = datetime.datetime.fromtimestamp(int(timest))
>>> print(newtime)
2019-01-30 17:14:07
>>>
BrechtSchamp
Kind of a big deal

Should be a unix timestamp indeed. I can't double check on my network as I get a timeout for that specific GET at the moment. I checked the similar /securityEvents and the ts there gives me a correct time.

 

1548864847 equals to January 30th, 2019. How are you doing the conversion?

cmiarshvac
Getting noticed

Sorry, the timestamp I used in my question was today's time. I was using that to illustrate the "form".  Actual data is more like:

 

1531233271.311001
HodyCrouch
Building a reputation

The endpoint /networks/[networkId]/clients/[id_or_mac_or_ip]/events includes parameters for startingAfter and endingBefore.  The documentation warns against client applications setting these parameters.

 

When you make a request to this API, the response includes a Link header.  For example:

 

Link: <https://n000.meraki.com/api/v0/networks/N_1234567890/clients/abc12345/events?startingAfter=1476908909.0>; rel=first, <https://n000.meraki.com/api/v0/networks/N_1234567890/clients/abc12345/events?startingAfter=1517256994.237001>; rel=next, <https://n000.meraki.com/api/v0/networks/N_1234567890/clients/abc12345/events?endingBefore=1548874564.0>; rel=last

You can use the values of startingAfter or endingBefore in the Link header to work your way through all events for a given client.

 

If you want to throw caution to the wind (as I might have done), you could try adding the endingAfter parameter to your original request and including the current unix epoch.

 

Otherwise, the API seems to return the oldest events.

Thank you for investigating and the detailed confirmation.

I did attempt to add the "startingAfter=<yesterday's timestamp>" to the client request query string.  For my test, it only return events "after" the supplied timestamp. This will work for my use case.  Thanks again to all for the help. 

Get notified when there are additional replies to this discussion.