canonical_dates is added to GET /api/v2/projects/service and GET /api/v2/projects/service/{id}. It contains the service dates as shown in Simplicate and API v3, with the same meaning for every invoice method.
Fields: time_frame, invoiceable_from, registration_time_frame and costs_registration_end_date
The existing date fields are unchanged
canonical_dates cannot be used to filter or sort
Validation of deadline_step and deadline_workflow was corrected when creating / editing workflows. Deadlines that were wrongly refused are now accepted.
For example, when submitting a new deadline_step without a deadline_workflow on a workflow that has no workflow deadline, it would be rejected when the date was in the future, because the missing workflow deadline was treated as today. It now correctly accepts the date and leaves the workflow deadline empty.
Affected endpoints:
POST /api/v2/workflows/workflow
PUT /api/v2/workflows/workflow/{id}
Workflows with one step:
A single date sets both deadlines, also when it is later or earlier than the stored deadline
A workflow can be created with only a deadline_step
Workflows without a workflow deadline:
A deadline_step can be set without a deadline_workflow
All other validation errors and their messages are unchanged
Submitting an invoice_number that is already in use now returns a validation error instead of a server error.
For example, when submitting a new invoice_number that already exists for the same my_organization_profile_id, it would be rejected with an HTTP 500 without a usable message. It now correctly returns an HTTP 400 with an error that names the duplicate invoice number.
Affected endpoints:
POST /api/v2/invoices/invoice
PUT /api/v2/invoices/invoice/{id}
Invoice numbers must be unique per organization profile. The same invoice_number on a different my_organization_profile_id is still accepted.
source_type is added to timeline message responses (GET /api/v2/timeline/message and GET /api/v2/timeline/message/{id}). It identifies what produced a timeline item as a string enum value ("ai" = AI-generated summary) and is null for unclassified items.
has_services is added for all linked_projects of a sale when fetched from GET /api/v2/sales/sales/{?id}
is_pending_for_sale_approval is added for all linked_projects of a sale when fetched from GET /api/v2/sales/sales/{?id}
POST/PUT to api/v2/project/service is now stricter about which IDs are accepted for hourtype_id. Only hourtype and itemtype prefixes are allowed. This prevents accidental mixup with project hour types.
The endpoint GET /api/v2/sales/sales/{?id} will also return the key linked_projects. This contains an array with some info about the projects that are linked with the sale. linked_projects. This contains the following keys:
id of the project
name of the project
project_number of the project
created_at the date when the project was created. It has the YYYY-MM-DD HH-MM-SS format
project_status:
id of the project status
label of the status
color of the status
POST /api/v2/projects/assignment now returns the id of the created record instead of a list of all records.
The endpoint GET /api/v2/hrm/leave will also return results without leave status.
Fixed inconsistencies in handling referenced entities. Referencing an invalid entity will now consistently result in a 400 Bad Request error. Affected endpoints are:
The fields is_editable and is_deletable are only included in the API response when explicitly requested via the select parameter. Affected endpoints are:
Previously the application erroneously returned "501: not implemented" status codes. These cases have been updated to more appropriate status codes. Most of these cases are now returning a "404: not found" status code.
In the new project service UI, you can set a specific registration timeframe. Several API calls have been updated to return the correct start_date and until_date for services. Affected endpoints are:
Add is_active property to a sale service resource indicating whether it was successfully created for endpoints:
GET /api/v2/sales/service
Contract change for POST /api/v2/projects/service
Newly created project services no longer contain the hour_types of the provided default service by default. You can still provide the hour_types you want to add to the service in the body.
In the GET /api/v2/hrm/absence endpoint:
The end_date field is empty when the absence is ongoing.
The field absence_ongoing indicates whether the absence is ongoing.
Add copy_latest_quote property when cloning sale to indicate if the last quote on the original sale should be copied
POST sales/sales/{id}/duplicate
Update the input types for POST /api/v2/customfields/option:
Updated GET api/v2/crm/organization with extra field
Added CustomerGroup value option
Updated GET api/v2/sales/salesreason
Added blocked property to response
Updated GET api/v2/sales/salesfilters with options that can be used to filter GET api/v2/sales/sales
Added opportunityprogress value options
Added administration value options
Added responsible_person value options
Updated PUT api/v2/sales/sales
It is now possible to change the relation of a Sales entity from an Organization to a Person or from a Person to
an Organization with person_id or organization_id respectively
Added 'is_active' (bool) to Person, Organization, and ContactPerson
models (/api/v2/crm/person, /api/v2/crm/organization and /api/v2/crm/contactperson)
Added separate model for updating assignments (PutAssignment) (PUT /api/v2/projects/assignment)
PutAssignment no longer accepts 'start_date' and 'end_date' properties; you can no longer modify dates through the
API (PUT /api/v2/projects/assignment)
Added 'start_date' and 'end_date' to PostAssignment specifically (POST /api/v2/projects/assignment)