This page contains a list of past and upcoming changes of our API. We try our best to prevent breaking changes, but sometimes we can't avoid it in order to release a new awesome feature 🚀
We are deprecating the endpoint
in favour of the new one:
This new endpoint will provide multiple user results in a single call, plus it has the option to fetch the details of the workload calculation.
The legacy endpoint will still be active up to 01.01.2023. Then it will be removed.
With the introduction of the project time bookings, we are migrating all the project member capacities to them.
As such, all the related endpoints are being deprecated and will not have any meaningful effect on the workload calculations:
We will remove those endpoints and the related data starting from 01.01.2023
Usermodel currently has a
CapacityPerWeekproperty, which we're removing soon. This property is getting it's own endpoint:
This endpoint has
PUTmethods to retrieve and edit the user's weekly capacity. The
GETmodel looks like this:
For a short time, both the property and the new endpoints will exist in parallel to be backward-compatible. We will remove the old property starting in March 2022. Please update your API client accordingly.
Currently, projects have one property called
IsBillableByDefault,which decides whether time entries created on that project are marked as billable or not. This is either set by the project template, or if no project template was used for creation, by whether the project has a company or not. In the case of a company, the times are marked as billed, otherwise the times are marked as not billable.
The problem is, that the project template always overrules this company rule. We need to have more flexibility here, so we change the
IsBillableByDefaultproperty on the project template from a
stringfield with the possible values:
on, off, auto.
autooption is set, the
IsBillableByDefaultof the project on project creation will be set according to the company rule, so
trueif a company is set and
falseif no company is set.
This release adds the highly requested feature to assign multiple users to the same task. As a result, we reworked the endpoints that allow assigning multiple users to tasks and task templates as well as automations.
If you want to use this feature, please enable the task setting "Allow multi-user assignment" in awork in the workspace settings page. Alternatively, you can activate the setting by calling the tasks/settings endpoint from below with the setting name
Additionally, these automation models were changed 🚨
For the action
assign-user-to-task, there is now an additional
removeOldAssignments. In order to assign multiple users to a task, you need the set this value to
false. You can also add multiple
assign-user-to-taskactions to an automation in order to assign multiple users for a single trigger.
For the actions
ActionValuenow has an array
assigneeIdsinstead of a single
assigneeId. However, you cannot assign multiple users to private tasks.
This feature is part of our big Einhorn release, which brought a bunch of awesome features and an updated UI framework 🦄
Project Templates used to be the Project Types, which now have a secondary role, similar to the Type of Work found on Tasks, to make it easier to understand for our users and remove some restrictions like creating a project without a Project Template.
Due to these complex changes, we completely reworked the existing Project Type endpoints and added new endpoints for Project Templates.
CRUD endpoints for project templates