User16681662815109981047 (Customer) asked a question.
Hii,
This is regarding the OKTA System Log API. As per the documentation of the OKTA API Reference (link), when we use the request parameter “since” in the API call, it will return the logs that have published values the same as the since value or greater than the since value.
But, when fetching the logs using the request parameter "since", I am also getting the logs that have published time less than the since value.
For Ex:
When I query the System Log API with since param value "2022-11-10T12:41:52.022Z",
The response contains the logs that have published time = "2022-11-10T12:41:51.926Z" which is actually published ~1 second earlier than the since value.
You can check the below-attached screenshot to verify.
Is it a known issue/limitation for the API?
Hi @User16681662815109981047 (Customer),
Thank you for posting on our Community page!
This is expected behaviour as /api/v1/logs requests containing the parameter "since" without also including the parameter "until" fall under the Polling requests category, for which the returned events are time filtered by their internal "persistence time" to avoid skipping records due to system delays, as mentioned in the documentation https://developer.okta.com/docs/reference/api/system-log/#polling-requests.
Hope this helps!
Thank you for reaching out to our Community and have a great day!
Thank you for your response @User16525341720043131322 (Management &).
I'm working on integration with System log API, what could be the maximum difference between internal "persistence time" and "published time" for this Polling requests category to take care of?
For example, will it be in a few seconds or in milliseconds?
Hi @User16681662815109981047 (Customer)
From what I noticed based on tests on my test tenant it never exceeded 150 milliseconds, but it may vary depending on a variety of factors. With this in mind, while theoretically possible, it is highly unlikely to reach or exceed a second, usually the average being 100 milliseconds (0.1s).
Thanks for the information @User16525341720043131322 (Management &)!
I see most of the time in polling requests category, events with less published times are also getting fetched in my tenant. (~200 milliseconds)
As mentioned in the docs, using until parameter with since parameter are called bounded requests and are guaranteed to be in order according to the published field.
In that, i see docs says that, "Not all events for the specified time range may be present — events may be delayed". To handle this using bounded requests, what buffer value we can keep in "until" parameter to get all events for live monitoring.
Ex. Without keeping any buffer in until parameter i got few events less (seems API takes some time to reflect all the generated events) and when i kept ~15 seconds buffer in until parameter of API calls, all events fetched.
Hi @User16525341720043131322 (Management &), I Hope you are doing well.
Just following up on the above question. Do you know what can be the expected maximum delay for API updates, when using "since" and "until" parameters for the latest data collection?