API Pagination Guide: Keyset Method + Best Practices

Keyset pagination (also called cursor-based pagination) is the recommended pattern for paginating through frequently-changing datasets like employee rosters in HRIS APIs. Understanding how it works and when to use it helps HR Tech teams build more reliable integrations.

What Is Keyset Pagination?

Instead of using an offset ("skip the first N records"), keyset pagination uses the last record from the previous page as a cursor to fetch the next set. You take a field from the last returned record (typically an ID or timestamp) and use it as the starting point for the next request.

Example: After fetching employees 1-100, you use the ID of employee 100 as the cursor for the next request.

Why Keyset Is Better Than Offset for HR Data

Offset pagination is unstable when data changes between requests. If an employee is added or deleted, the offset shifts and you either see duplicates or miss records.

Keyset pagination anchors to a specific record. New inserts or deletes don't shift the cursor, so you get a consistent, complete page of results every time.

For employee rosters that change daily (new hires, terminations, status changes), keyset pagination ensures your sync doesn't miss records during the process.

Implementation Pattern

The basic pattern: make your first request without a cursor; extract the cursor field (typically the last record's ID or created_at timestamp) from the response; pass it as a parameter in subsequent requests; continue until the response indicates no more pages.

How Bindbee Handles Pagination

Different HRIS systems use different pagination patterns. Some use offset, some use cursors, some use tokens. Bindbee normalizes pagination across all 65+ connected systems, so your product uses one consistent approach regardless of the underlying implementation.

Book a demo to see how Bindbee normalizes pagination across 65+ HR systems.