Migrate list calls from v1

The v1 audit and coding evaluation lists page by number, and the v1 user and question set lists return every record at once. Every v2 list pages by cursor.

POST /v1/audits and POST /v1/coding take page and pageSize (default 1,000) and return a bare array. v2 lists are GET requests that return { "object": "list", "data": [...], "has_more": true }, with limit from 1 to 100 (default 20); limit=1000 returns 400 VALIDATION_ERROR.

The response has no next_cursor field. To get the next page, pass the last item's id (audit_id for audits) as starting_after, and repeat until has_more is false. At limit=100, 1,000 audits take ten requests.

For a second page, v1 takes "page": 2 and v2 takes the last audit_id of the first page as starting_after (here a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d):

- POST /v1/audits
- { "status": ["complete"], "page": 2, "pageSize": 1000 }
+ GET /v2/audits?status=complete&limit=100
+     &starting_after=a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d

For the pagination loop in code, batch get by id (?audit_id=<id>&audit_id=<id> or ?audit_id=<id>,<id>) and include_total=true, which adds total_count, see Page through and filter lists.

A query string over 2,048 bytes is rejected with a bare 403 and no JSON body. About 44 repeated audit_id values or about 50 comma-separated ids fit in one request, so split larger batches.

If you poll v1 with lastUpdatedStartDate, poll v2 with updated_after and updated_before windows that overlap. For a sync loop in code, see Keep audits in sync with updated_after.

Next