## TL;DR
Follow the next link header exactly as returned and never construct page URLs by hand. Handle 429s with backoff on the same URL, and stop when no next link appears.

```text
how to fix Okta System Log API pagination errors
```

## Use this when
- Paging the System Log skips events or repeats them.
- A hand-built page URL returns errors.
- A poller loses its place after a 429.

## Not for this skill when
- Large ranges time out. Slice by time first, then page each slice.
- The API returns 401. That is auth, not pagination.
- Events are missing with no paging involved. Check retention.

## Steps
1. Start with since, until, limit 1000, and ascending sort order. Verify: the first page returns.
2. Read the next link from the response Link header. Verify: you are using the header value verbatim.
3. Request the next URL exactly as given, without rebuilding it. Verify: each page advances.
4. On 429, back off and retry the same URL. Verify: the retry resumes the same page.
5. Stop when no next link appears. Verify: the event stream is continuous.

## Variant phrasings
### Okta System Log next link
The mechanism-first phrasing.
### pagination 400
The status-first search.
### System Log API cursor
The concept-first phrasing.

Compatibility: Okta System Log API (events v1), Classic and Okta Identity Engine.

## Why it happens
The next URL encodes the pagination cursor. Hand-built URLs guess the cursor format and skip or repeat events; the header value is the only correct continuation.

## Edge cases / pitfalls
- The Link header is absent when results fit in one page; that is normal, not an error.
- Clock skew making since miss the newest events; poll slightly behind real time.
- Some HTTP clients hide the Link header; inspect raw headers when debugging.
- Changing sort order mid-pagination invalidates the cursor; pick one order and keep it.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_z6TK-yOw0cVJa4GU9SCY1Q