## Overview
This endpoint pages through approval instance IDs by template (process_code) and time window — the first step of DingTalk approval data integration: collect IDs here, then call topapi/processinstance/get for each instance's detail (form component values, approval trail, status). Typical flows: expense reports into ERP payables/vouchers, purchase requisitions into purchase orders, connecting OA to finance.
### Request essentials
1. POST with Content-Type: application/json; access_token rides in the URL query.
2. Body: process_code (required), start_time (ms epoch, required), end_time (optional, at most 120 days after start), size (up to 20 per page), cursor (0 for the first page).
3. result.list holds instance IDs; has_more tells whether to continue with next_cursor.
4. The window caps at 120 days — backfill history month by month; for incremental sync advance start_time as the cursor with a few minutes of overlap.
### Integration advice
- Form values live in form_component_values of the instance detail; component labels/values shift with template versions, so drive mappings from a maintainable dictionary instead of hard-coded indexes.
- Qeasy syncs approvals with process_instance_id as the idempotency key and writes only COMPLETED instances into the ERP.
### Detail fetch strategy
Listings return IDs only, so budget one detail call per instance and throttle accordingly — a 20-ID page typically means twenty follow-up calls. Cache instance details immutably once an instance reaches COMPLETED or TERMINATED, because terminal instances never change; this removes most repeat traffic when a window is replayed after a failure.