Record attendance

Marks recorded by something you run — a turnstile of your own, a kiosk, your app.

datetime carries its own offset and is the only place time is stated — send 2026-08-10T09:03:00+05:00 and 09:03:00 goes on file with +05:00 beside it. There is no separate timezone field, and the offset is not optional: the wall clock and the zone are read off that one value, so they cannot disagree. A mark may not be dated in the future, nor more than 24 hours back: older than that is history being rewritten, and lateness already computed against the day would move under it.

status is in, out or break, and the answer echoes it back in those words, with the moment as the instant it was recorded at — the same shapes the listing answers with.

A mark already on file for the same person, moment and direction is not written again, whether it repeats across two requests or inside one. There is no key you own on this resource, so no promise of idempotency is made in general — but a retried upload will not double somebody's day. The answer says created or unchanged per item, with the id either way.

The shift a mark belongs to is worked out afterwards, so shift_id is yours to send only if you already know it.