Connect each employer via Finch Connect with the organization, directory, individual, employment, payment, and pay_statement product scopes enabled
On initial load, paginate through GET /employer/directory to build the employee roster; then GET /employer/individual and /employer/employment for each individual to capture demographic and job data
Retrieve the historical payment list via GET /employer/payment for each employer, filtered by start_date and end_date
Fetch pay statements for each payment in batches via POST /employer/pay-statement using the payment_id array; handle 202 Accepted responses by polling the job status endpoint
Deduplicate and normalize all records to a canonical schema keyed by employer_id and individual_id; store raw Finch payloads as a backup
Register a Finch webhook endpoint for the data.sync.all event to trigger incremental refreshes when provider data is updated
Known gotchas
Finch's /employer/individual endpoint is paginated; large organizations require multiple pages — use the paging.next cursor to retrieve all pages before building downstream aggregations
The 202 Accepted pattern on pay statements means responses may not be immediately available — build retry logic with exponential backoff rather than sequential blocking waits
Individual IDs are stable within Finch per provider connection but are not portable across providers; use employer-issued IDs (e.g., SSN or employee number) as the cross-provider join key with appropriate security controls
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp