Skip to main content
Timekeeping is available through /time-entries and /timesheets, with matching detail reads. Time entries contain effective corrected start/end instants, correction flags, raw elapsed minutes, recorded activity/payable state, and work/member links. Custom activity names retain their recorded text. Missing or ambiguous activity produces null activity and payable fields; it does not create duplicate intervals or an inferred activity.

Read entries and a configured period

Time-entry filters and corrections

starts_from is inclusive and starts_before exclusive, matching effective start instants rather than interval overlap. Entry collections order by creation instant and ID, including timestamp ties. Filters include member, job, appointment, assignment, exact activity name, payable state, open state, and creation/effective-start bounds. Lists and details require include_deleted=true to return retained soft-deleted entries. The entry’s modification timestamp is unavailable, so updated_since is unsupported. Refresh known IDs and bounded effective-start windows to observe corrections and deletions; a correction can move an entry into another window. Current relationships and hard deletions require customer reconciliation, as with the other collections.

Timesheet identity and period

Timesheets require one company-local period_date and resolve the current configured period containing it. Results identify the member plus inclusive period.start_date and exclusive period.end_date_exclusive; these form the customer-side key. Use that exclusive end as period_date for the next period. Page members by cursor, or use team_member_id to select one; /timesheets/{team_member_id}?period_date=... returns the same member representation. All current company members are included, regardless of role or active state, including zero-entry members. Changing company period settings can change historical results and invalidates cursors whose resolved boundaries change. Missing or unusable settings return 400; disabled tracking still permits reads of retained data. There is no historical configuration snapshot or fabricated timesheet ID.

Payable minutes

Timesheet inputs are nondeleted entries starting within the resolved local period. The response includes entry, open-entry, and unknown-activity counts, every local day (including zeros), and total payable minutes. Only completed entries with a known payable activity contribute minutes. Totals follow the existing server timesheet calculation: whole wall-clock minutes, a running daily clamp of 0–1,439, and overnight time only through the end of its starting day. Negative/overlapping records follow those same recorded-data rules. Last-day overnight entries follow the same rule as other overnights. duration_minutes on the entry remains fractional elapsed time across its whole span. For example, a corrected on-site entry from 12:30 to 13:30:30 has 60.5 elapsed minutes and contributes 60 payable timesheet minutes. A 22:00–02:00 overnight contributes 119 minutes to its starting day. In Los Angeles, the spring daylight-saving interval 01:30–03:30 and fall interval 00:30–02:30 each contribute 120 wall-clock timesheet minutes, while raw elapsed durations are 60 and 180 minutes. Existing browser summaries can differ with the browser timezone and their end-containment selection. These resources describe current corrected timekeeping; they do not calculate payroll, overtime, wages, approvals, or job-cost labor amounts.

Supported period configuration

Configured periods are bounded to 366 calendar days. Supported cadences are daily (interval 1–366), weekly (1–52), monthly (1–12), and yearly (1), using the settings page’s weekday and month-day/ordinal modes. Anchor time-of-day is normalized to its company-local calendar date. Recurrence phase stays anchored when requesting historical periods. Date-based month/year boundaries clamp to the target month’s end (January 31 → February 28 → March 31; February 29 returns in leap years); an absent fifth weekday is skipped. Unsupported or nonprogressing recurrence settings return the same configuration-unavailable 400, without a fabricated fallback period.