Timekeeping

Calculated timesheet data for a resort, with wage, commission and incentive figures already computed against the configured rate cards. Use this group to ingest payroll-ready data into payroll exports, BI dashboards, or commission audit systems.

Pages in this group

• Paid Activities by Date Range — paid-activity rows with computed wages and commission in a single feed (GET /api/timekeeping/paidactivities/paidactivitiesbydaterange).

• Wages by Date Range — base activity wage only, one row per timesheet entry (GET /api/timekeeping/wages).

• Incentives by Date Range — staff incentives and commissions, one row per entry per component (GET /api/timekeeping/incentives).

All three take the same query parameters: startDate, endDate, updatedAfterLocalDateTime and seasonId.

Which feed should I use?

Paid Activities is not deprecated. It remains fully supported and is in production use today. Wages and Incentives are complementary — an alternative shape for integrations that want the two components separated, not a replacement.

If you want...	Use
One row per timesheet entry with wages and commission together	Paid Activities by Date Range
Base wages and incentives as separate feeds, each with its own pay codes and cost centres	Wages + Incentives

Choose one approach or the other. Pulling the combined feed and the split feeds for the same period will double-count.

Wages and Incentives have different grains. Wages returns one row per timesheet entry; Incentives returns one row per entry per incentive component. There is no entry-level join key between them — incentive rows are self-contained by design — so the two cannot be summed naively.

Typical use

• Payroll export — pull the rows for a payroll period and feed into the payroll system. Wage, commission, and totals are already calculated; pay codes and cost centres are included for downstream allocation.

• Commission audit — pull a wider range and reconcile against the resort's expected wage/commission outputs.

• Incremental sync — pass updatedAfterLocalDateTime to receive only rows changed since your last successful pull. Note that this timestamp is interpreted in resort-local time, not UTC — convert using the timezone from Resort Details.