> For the complete documentation index, see [llms.txt](https://docs.samesystem.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.samesystem.dev/business-guides/scheduling/time-registrations.md).

# Time registrations

{% hint style="info" %}
Only available in API v1
{% endhint %}

Time registrations include both pre-time registrations and the actual time registrations. It is possible to use this information to calculate deviations in time registrations and how much an employee is late.

**Pre-time registration** represents how a shift was scheduled at the time the shift was due to start or when the employee checked in. It provides a snapshot of the shift at that specific point in time.

This differs from the **Planned schedule**, which represents how the schedule looked when it was originally published to the employees.

It is possible to:

* [Fetch time registrations.](/api-v1-reference/schedule/get-time-registrations.md)
* [Import time registrations.](/api-v1-reference/schedule/import-time-registrations.md)
* [Start time registration](/api-v1-reference/schedule/start-time-registration.md) (check in or return from break).
* [Stop time registration](/api-v1-reference/schedule/stop-time-registration.md) (check out or start a break).

### Fetch time registrations

#### 93-day maximum date-range limit

We have a 93-day maximum date-range limit. If you try to fetch data for more than 93 days, you will receive an error.

### Start and stop time registration

SameSystem provides **Start Time Registration** and **Stop Time Registration** endpoints for integrations with third-party time and attendance solutions.

These endpoints allow an external system to register employee clock-ins and clock-outs directly in SameSystem. This makes it possible to use external solutions such as physical time clocks, POS systems, access control systems, or other time registration applications while keeping SameSystem as the central system for workforce and attendance data.

A typical working day may look like this:

1. **Start of shift:** \
   The employee clocks in and the integration calls **Start Time Registration**.
2. **Start of break:**\
   The employee clocks out and the integration calls **Stop Time Registration**.
3. **End of break:** \
   The employee clocks back in and the integration calls **Start Time Registration**.
4. **End of shift:** \
   The employee clocks out and the integration calls **Stop Time Registration**.

Employees must therefore also clock out when starting a break and clock back in when returning from the break. Each period of working time is represented by a start and stop registration.

This approach is intended for customers where employees register their working time in a third-party solution while the resulting time registrations need to be available in SameSystem for attendance, payroll, and other downstream processes.

{% hint style="info" %}
This feature is protected by the `real_time_time_registrations_API` feature flipper flag per client. 

Contact <integrations@samesystem.com> to open for this feature.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.samesystem.dev/business-guides/scheduling/time-registrations.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.