System Log API polling requests: which timestamp does since filter on, and can next links skip late-inserted events?

Hello @AP.90624 (Customer)​ Thank you for posting on our Community page!

You are asking whether the since parameter on /api/v1/logs filters by persistence (insertion) time or published time in polling requests, whether late-inserted events can be skipped by a next-link cursor, what the delay bounds are between publish and visibility, and how long next links remain valid.

Summary: In polling requests, since filters on persistence time. The published documentation does not state a maximum commit delay, a next-link lifetime, or an expiry error, so those limits should be confirmed with Okta Support for your tenant.

Solution: The System Log API reference defines since as a lower bound on the published property for bounded queries and on persistence time for polling queries. This means the polling behavior you described is documented for the current reference.

Answers to each question:

1. Polling requests: since filters by persistence time. Bounded requests (those using since and until for a time range) filter by published time. The System Log API reference documents both behaviors.
2. Late-inserted events and cursors: The documentation does not describe a commit-visibility guarantee that rules out a late-inserted event landing behind a cursor that has already advanced. A community thread mentions a delay of more than one minute in polling, but that is not an official specification. Confirm the guarantee with Okta Support before relying on it. Regardless of the answer, a resilient ingestion design overlaps each new polling window with the previous one and deduplicates on the event uuid.
3. Visibility delay: The published documentation does not give an upper bound or a typical figure for the delay between an event's published time and its visibility in bounded or polling requests. Obtain this figure from Okta Support.
4. Next link validity and errors: The documentation does not state how long a next link remains valid or what error an expired or invalid link returns. For a pause of a day or more, store the last processed next link, and if it fails, restart with a since value that overlaps the last processed event and deduplicate. Confirm the expiry behavior and error response with Okta Support.

Steps for a resilient polling loop:

1. Store the next link and the published and uuid of the last processed event after each page.
2. Request /api/v1/logs with sortOrder=ASCENDING and since set to a value a few minutes before the stored position.
3. Deduplicate incoming events by uuid so that overlapping windows do not create duplicates.
4. Follow next links until no further page is returned, then wait before the next poll.
5. Restart from an overlapping since value if a stored next link is rejected.

Thank you for reaching out to our Community and have a great day!

--

Help others in the community by liking or hitting Select as Best if this response helped you.