Deprecation of Attendances and Projects V1 Endpoints

The attendance and projects v1 endpoints will be deprecated in favor of their v2 versions with the final deprecation date set for Aug 30, 2026. All integrations using these v1 endpoints must migrate to the v2 APIs to ensure continued service for our mutual customers. Please share this important update with your technical team.

Migration Guidance:

• Update integrations to use v2 endpoints for Attendance and Projects.
• Consider the possibility of attendance periods going overnight (see below).

Notes regarding differences between the v2 and v1 endpoints:

• For Attendances:
  • Change the request URLs from v1 to v2.
  • The attendance period id is now a string (UUID) and not a numeric id, and there is a GET endpoint to get a specific period, and a List endpoint to search for periods by specific criteria.
  • The response object structure changes slightly as documented in the Attendance Periods public API reference.
  • Currently, a period's start and end date will be on the same day, but that should not be an assumption made, as periods will be possible to go overnight in the future. See the sample payload below.
  • Attendance periods have a period type: work or break. In v1, only work periods could be managed, and it was possible to define a certain break duration within the work time range, but not when that break was exactly. With v2, the model matches closely what the user-facing UI shows, defining a start and end time for breaks.
  • Information on whether there was a holiday or absence on a certain date is not provided by the Attendance v2 endpoints and can be obtained by querying the absence-related public API endpoints.
  • When creating an attendance period (POST) in v1, it would skip approvals. In v2, this is a request parameter option, which defaults to requiring approval. For skipping approval, ?skip_approval=true should be used.
  • The create response includes the UUID of the newly created period. Note that it's possible for a period creation to result in creating or affecting a number of periods, e.g., when automatic compliance breaks are enabled. All affected periods are returned in the affected_periods response object.
  • The v2 API also provides webhooks to not require polling for updates
• For Projects:
  • The URLs need to be changed from v1 to v2.
  • On the CreateProject endpoint instead, of passing active=true/false, you need to pass status=ACTIVE/ARCHIVED.
  • New additional Project attributes are returned by the GET endpoints and can be set by the PUT/POST endpoints. The new subprojects are modeled by projects having parent_project.id set. Subprojects do not support all project attributes.
  • The ListProjects endpoint offers a number of filtering capabilities by the new project attributes.
  • If the response object for Get and List should also include the computationally expensive fields tracked_minutes, sub_projects_tracked_minutes, sub_projects_count or tracked_periods_count, then these field names need to be passed in to the includes request parameter.
  • New endpoints exist for managing employee assignment to projects. For projects that have not been assigned to any individual, the assigned_to_all attribute controls whether it is available to all employees to track or to none

Sample Payload for Overnight Attendance Period (v2)

{
  "id": "bd242cd1-5116-41a0-99aa-c12af4837c81",
  "person": {
    "id": "1234"
  },
  "type": "WORK",
  "approval": {
    "status": "PENDING"
  },
  "start": {
    "date_time": "2026-06-07T22:00:00"
  },
  "end": {
    "date_time": "2026-06-08T05:00:00"
  },
  "created_at": "2026-06-07T11:17:30Z",
  "updated_at": "2026-06-07T05:07:00Z",
  "comment": "Comment associated with this attendance period.",
  "is_auto_generated": false,
  "project": {
    "id": "82173"
  }
}