Employees on this Edays system with partner_id (the key other tools take), name, job title, leaver flag, settings template, start dates, FTE and hours per day. GET /api/v2/users is not marked as paged in the documentation; the whole list is fetched (following the edays-pagination-* headers page by page if the system does page it) and filtered locally: query matches part of the name or partner ID, and leavers are skipped unless asked for. Contact and HR details (email, login, phones, address, next of kin, date of birth, payroll and employee numbers, pay) only with include_contact_details.

One employee by partner ID, with the groups they belong to (team, location and so on) and their authorisation hierarchy (who approves their requests: step one and step two authorisers and alternates, as partner IDs). Contact and HR details only with include_contact_details.

Absence records (holiday, sickness and other absence types) across the system or for one user, with status, start and end, duration and the absence_type_id (name it with list_absence_types). Filters are sent to the API as documented: date_from/date_to (datestart/dateend), record_type (1 planned, 2 unplanned), absence_type_id, and on the system-wide endpoint also user_id (Edays GUID), group_id, created_since and modified_since. With partner_user_id the per-user endpoint GET /api/v2/users/{id}/absences is used instead, which documents only the first three filters. Whole API pages of min(100, max_results) records are returned; the note says how to continue. Payroll and employee numbers only with include_contact_details.

One absence record by its GUID: user, absence type, status, start and end, duration, time unit, created and modified dates. Payroll and employee numbers only with include_contact_details.

The absence types configured on the system (Holiday, Sickness and so on) with their record type (1 planned, 2 unplanned) and booking and calendar-visibility flags. The API also returns Custom Day Groups (record type discriminator 5) and Public Holiday Groups (6) from the same endpoint; they are kept unless record_type filters them out.

Entitlement balances for one user. Deducting entitlements (holiday and the like, which count down: annual entitlement, transfers, pending, booked, taken, untaken, remaining, per booking period and element) and summing entitlements (sickness and the like, which count up: year to date, last 6 and 3 months, last 30 days), plus the entitlement pots they belong to. Booking period and time unit numbers are named from the documented lists (Current, MinusOne, PlusOne; Days, Minutes, Hours).

The rota (working pattern) assignments of one user with their start dates, named from the system's rota list, and with include_patterns the public holiday and custom day patterns applied to the user, named from those lists. Up to six API calls.

The public holiday patterns held in the system (for example 'UK Public Holidays') and, with include_custom_days, the custom day patterns (for example 'Christmas Shutdown'), as id and name. The API lists the patterns only; the dates inside a pattern are not exposed by API V2.

The group types on the system (Country, Location, Team and so on) and the groups within each (England, Nottingham, Programming), with partner IDs. One call for the types plus one per type for its groups; give group_type_partner_id to fetch a single type.