Okta Workforce Identity

What the API exposes

• A System Log API at /api/v1/logs giving near real-time read access to org events, returning 100 objects per request by default.
• Two request modes with different guarantees. A polling request, meaning until is unspecified and sortOrder is ASCENDING, returns every event in the org, ordered by internal persistence time, and has an infinite number of pages so a next link is always present even when the page is empty. A bounded request, meaning both since and until are set, is ordered and filtered by the published field and ends.
• Link header pagination. Responses always carry a self link and may carry a next link, and Okta's own guidance for exporting to another system is to follow the next links rather than paginate by time yourself.
• SCIM style filter expressions on eventType, actor.id, target.id, client.ipAddress and outcome.result, with eq, ne, sw, ew and co operators, plus a keyword q parameter.
• Correlation identifiers on every event, specifically authenticationContext.externalSessionId, transaction.id and authenticationContext.rootSessionId, which is what makes reconstructing a session across events actually possible.
• Both authentication models. Proprietary SSWS API tokens work, and scoped OAuth 2.0 access tokens work and are what Okta recommends, with per-resource scopes such as okta.logs.read, okta.users.read, okta.groups.read and okta.apps.read.
• Log Streaming, a push path configured in the admin console under Reports, Log Streaming, which sends System Log events to a target without you writing a poller.
• Rate limit telemetry as first-class data. Okta writes system.org.rate_limit.warning, system.org.rate_limit.burst and system.org.rate_limit.violation events into the System Log itself, so your throttling problems are visible in the same place as everything else.
• SCIM 2.0 outbound provisioning to downstream applications, sold as Lifecycle Management.

What it cannot do

• Return anything older than 90 days. System Log data past the retention window is simply not returned. The query still succeeds, which is the dangerous part, so a backfill that silently comes back short looks like a successful run.
• Guarantee ordering on a polling request. Polling results are ordered by internal persistence time and may come back out of order by the published timestamp. If your downstream sorts on published and assumes monotonicity, it will be wrong.
• Guarantee completeness on a bounded request either. Okta's own wording is that not all events for the specified time range may be present, and that such delays are rare but possible.
• Let you craft the after parameter. It is system generated for next links, and since and after are mutually exclusive.
• Run a query for longer than 30 seconds. Individual queries time out there.
• Tell you your own rate limit from the documentation. Quotas vary by service subscription, HTTP method, license count and add-ons such as DynamicScale, so the published pages describe the bucket mechanics but not your numbers. You read them from the response headers and the rate limit dashboard.

Capabilities

Connects to

Evidence