Attendance Data - Pagination

The Attendance API uses cursor-based pagination to allow apps to fetch large sets of attendance records efficiently and reliably. This approach ensures consistent traversal of results, even as new data is added to the system.

How Pagination Works

Records are returned in a stable order based on the composite sort key:

(date, student_id, section_id, school_id) //student_id, section_id, and school_id are Clever-generated identifiers.

If the response includes more records than can fit on one page, it will contain a starting_after token referencing the last record returned. Use this token in the next request to retrieve the following page.

GET /v3.1/attendance/schools/{school_id}?
  date_range_start=2025-04-01&date_range_end=2025-04-01&limit=100&starting_after=MjAyNS0wNC0wMV82N2Y0MjE2OTJlZGEwZTNmYTE4ODBlNTNfNjdmNDIxNjkyZWRhMGUzZmExODgwZThkXzY3ZjQyMTY5MmVkYTBlM2ZhMTg4MGU0Zg==

What the Cursor Represents

The starting_after cursor is a base64-encoded string representing a composite key made up of:

• date
• student_id (Clever ID)
• section_id (Clever ID)
• school_id (Clever ID)

When decoded, a cursor might look like:

2025-04-01_67f421692eda0e3fa1880e53_67f421692eda0e3fa1880e8d_67f421692eda0e3fa1880e4f

If one or more fields are missing for a given record (e.g., a section or student ID), that position is filled with a zero-padded placeholder matching the length of a standard ID (24 characters):

2025-04-01_67f421692eda0e3fa1880e53_000000000000000000000000_67f421692eda0e3fa1880e4f

❗️

You do not need to decode cursors params

Simply pass the starting_after token from one response into the next request to paginate through results.

Why Base64 Encoding?

We encode cursors in base64 to:

• Represent composite keys in a compact, consistent format
• Allow future schema flexibility without breaking existing integrations

While the cursor can technically be decoded, it is intentionally designed to be treated as an opaque value.

Record Uniqueness

Attendance records are uniquely identified by the combination of:

• date
• student_id
• section_id
• school_id

Only one record is expected per unique combination per day. If a record with the same key appears again, it should be interpreted as an incremental update or overwrite of the existing record.