> 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/whats-new/readme.md).

# What's new?

New updates and improvements

{% updates format="full" %}
{% update date="2026-10-09" %}

## Tasks

Added support to fetch information about tasks registered in each shifts. In order to fetch tasks, you can include `?tasks=true` and the response will include an array of `scheduleTask` objects under `tasks`.

Please look in [Planned schedule/actual schedule.](/api-v1-reference/schedule/get-planned-actual-schedule.md)
{% endupdate %}

{% update date="2026-09-28" %}

## Absence balance timelines

You can now read absence balances for both the current and the next absence period in one request, using the new endpoint:

`POST /api/v2/{clientToken}/absence_balance_timelines`

Send the user IDs and absence type IDs you're interested in, and you'll get one timeline per user and absence type, with a balance for each period. Add `periodBalances.absenceStartDate` and `periodBalances.absenceEndDate` to your field filter to see the exact dates of each period.

[Read documentation](https://docs.samesystem.dev/business-guides/absence/absence-balances/fetch-absence-balances-for-current-next-period)

[API v2 reference - Absence Balance Timelines](/api-v2-reference/absence-balance-timelines/post-client-token-absence-balance-timelines.md)
{% endupdate %}

{% update date="2026-09-28" %}

## Balance transfers for closed salary periods

You can now trigger a balance transfer through the API, even after the salary periods involved are confirmed and closed. There's no need to reopen periods, unconfirm and reconfirm days, or close them again.

This helps when data in a confirmed period changes afterwards. For example, a retroactively approved sickness absence might change how many hours a day contributes to the balance. The endpoint recalculates the balance and carries it forward, so stored balances match actual balances again.

[Read the documentation](/api-v2-reference/balance-transfers.md)
{% endupdate %}

{% update date="2026-09-22" %}

## Schedule endpoint - bonus type information

We added information about the bonus type in the bonus object for the Schedule. This can be used if you need to know the rate or use the id of the bonus type in an integration.\
[Actual schedule](/business-guides/scheduling/actual-schedule.md)

[Planned schedule](/business-guides/scheduling/planned-schedule.md)

[API Reference ](/api-v1-reference/schedule.md)

```json
{
                "name": "Bonus Weekdays >18:00 ",
                "start_time": 21.5,
                "end_time": 23.25,
                "amount": 1.75,
                "cost": 35.0,
                "bonus_type_id": 30525,
                "bonus_type_rate": 20.0,
                "bonus_type_rate_type": null
 }

```

{% endupdate %}

{% update date="2026-09-17" %}

## Lent out information in time registrations

Added support for identifying users temporarily assigned (lent out) to another department. When using `?include_lent_out=true`, the response now includes a `lent_out_department` object showing the department the user is assigned to for the shift, while the existing `department` object continues to represent the user's normal department.

[GET /api/v1/{clientToken}/export/time\_registrations](/api-v1-reference/schedule/get-time-registrations.md#get-clienttoken-export-time_registrations)
{% endupdate %}

{% update date="2026-09-10" %}

## Advanced settings endpoints

### Advanced Minimum Staffing

We have added new API endpoints for **Advanced Minimum Staffing**, in our API v1, making it possible to read and manage minimum staffing requirements programmatically.

You can now:

* Define minimum staffing by weekday and hour
* Apply different staffing requirements for specific date periods
* Manage settings centrally at client level
* Create department-specific overrides when local staffing needs different settings.

See [**Advanced Minimum Staffing**](/business-guides/forecast/advanced-minimum-staffing.md) in our Business Guides and API documentation for more details.

### Advanced Employee Capacity API

You can now manage **Advanced Employee Capacity** through the API v1.

The new endpoints allow you to configure capacity tiers based on the number of visitors or customers, with different capacity values by weekday and hour. Settings can be managed at both client and department level, making it possible to automate advanced forecasting configurations across your organization.

See the  [**Advanced Employee Capacity**](/business-guides/forecast/advanced-employee-capacity.md) documentation for endpoint details and examples.
{% endupdate %}

{% update date="2026-08-31" %}

## Productive hours - details

Added information about how we calculate productive hours for the daily\_stats endpoint.

Please have a look: [Productive hours](/business-guides/scheduling/productive-hours.md)
{% endupdate %}

{% update date="2026-08-28" %}

## Absence balances

Added information about absence balances and how to update these if needed.

Look in [Absence balances](/business-guides/absence/absence-balances.md).
{% endupdate %}

{% update date="2026-08-25" %}

## AbsenceLogs - start and end time inserted

Added `startTime` and `endTime` to absence logs for absences that are **not full-day absences**.

This makes it possible for integrations to track changes to the start and end times of an absence, in addition to changes to dates and other absence information.

Look in [Fetch absence logs](/business-guides/absence/absence/fetch-absence-logs.md)
{% endupdate %}

{% update date="2026-08-21" tags="feature,improvement,fix" %}

## New API documentation portal

We have launched a new **SameSystem API Documentation Portal** to make it easier to develop and maintain integrations with SameSystem.

The new portal brings our API references, integration guides, examples, and best practices together in one place.

#### New OpenAPI Specification for API v1

As part of the new documentation portal, API v1 is now documented using an OpenAPI specification.

This provides:

* A structured and searchable API reference
* Detailed endpoint descriptions
* Request parameters and response schemas
* Request and response examples
* Easier exploration of available API functionality
* Support for development tools that can consume OpenAPI specifications

The new OpenAPI reference replaces our previous API v1 reference documentation as the primary technical reference.
{% endupdate %}
{% endupdates %}


---

# 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/whats-new/readme.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.