List clock-ins
Changed onMarks inside a window of days, oldest first.
The window is required and capped at 90 days. This is the largest table in the product; an unbounded read of it has no plan that finishes. date_from and date_to are plain dates matched against the clock the mark was stamped with, not against an instant — a day means the same thing here as it does to the person who worked it.
datetime is the moment as it was recorded, offset included — the stored wall clock read in the stored zone, never shifted anywhere else. It is one field because it is one fact: the wall clock is the value without its offset, and the zone is the offset. On the rare row whose zone cannot be read it comes back with no offset at all, which is how you see that the zone was not known.
status is in, out or break, not the integer the column keeps.
Late arrivals are the one thing to plan for: a device that was offline uploads what it recorded earlier, so a mark can appear inside a window you have already read. Re-read the last few days with overlap rather than paging strictly forward and never looking back.
Request
- Base URL: https://api.clockster.com
- URL: https://api.clockster.com/company/v3/attendance
- Auth: HTTP bearer
Query parameters
Start of the window, inclusive (YYYY-MM-DD).
End of the window, inclusive (YYYY-MM-DD).
How many rows one page holds. Defaults to 50.
The meta.next_cursor of the previous page. Omit it for the first. A cursor is bound to the filters it was issued under — change them and start again.
Only rows belonging to these people, by id.
Only these locations, by id.
Only rows in these states.
Only marks recorded this way — a device, the mobile app, or a person entering them by hand.
Relations to load, comma-separated. Anything not named is absent from the answer rather than null.
Response
Success
Changes
- info
the endpoint scheme security
companyTokenwas added to the API
- info
- breaking
removed the required property
//from the response with the status
- breaking