We’ve enhanced the Get the details of an existing time off request endpoint to support more precise tracking of time off usage. This will help you gain deeper insights into time off usage with per-day cost values and optional daily breakdowns in the response.

Responses now include a new cost field per day, showing the amount of time deducted from the employee’s balance for that day. This unlocks better visibility and control for payroll, reporting, and integration workflows.

To enable this daily view for multi-day requests, use the includeDailyBreakdown query parameter (default: true).

📌 What’s changed?

• All multi-day time off requests now include a durations array in the response payload when requested to include a daily breakdown/
• Each day includes a new cost field, indicating how much time is deducted per day
• New query parameter: includeDailyBreakdown (boolean, default true)
• Duration array is returned only when includeDailyBreakdown=true

📘

Notes:

• The cost field is additive to the existing totalCost field and enables more granular day-by-day tracking
• For single-day requests, the cost and totalCost will be the same
• The cost value is calculated according to the time off policy's unit (either days or hours) and excludes non-working days like weekends or holidays.

Affected endpoints

• Get the details of an existing time off request

The Attendance API has been extended to support full lifecycle management of project tasks.

What’s new

• Developers can now programmatically create, update, archive, and restore project tasks, enabling deeper integration with external project and time-tracking systems.
• Previously, the API exposed only project task metadata and search endpoints, limiting integrations to read-only access to project tasks.

New endpoints

• Create project task(s): Supports bulk creation of up to 100 tasks per request. Tasks are created as active by default.
• Update project task: Replaces the existing task record with the provided payload. The task status cannot be updated via this endpoint.
• Archive project task: Sets the task status to archived. Archived tasks remain queryable but cannot be selected for new attendance entries.
• Restore project task: Restores an archived task, making it available for attendance entry selection again.

Notes for developers

• ✅ No action required. These changes are non-breaking and additive.
• Task status (active or archived) is managed exclusively via the archive and restore endpoints.
• The update endpoint performs a full replacement of the task record, so existing task data should be retrieved before updating to avoid data loss.
• Bulk operations are supported for task creation, with a maximum of 100 tasks per request.

For full details, see Projects API.

The Attendance API now enables developers to programmatically query calculated attendance data from Bob. Previously, this calculated data was available only through the Bob UI and reports.

New endpoints

• Fetch attendance summaries:
  • Returns aggregated attendance data per employee for a specified date range.
  • The response reflects policy-based calculations, including worked hours, payable hours, overtime, breaks, offsets, and premium-eligible hours.
• Fetch daily attendance breakdown:
  • Provides a day-by-day view of attendance calculations per employee.
  • Each record represents one employee on one date and shows how hours are calculated at the daily level, including regular time, overtime, breaks, and premium-eligible hours.
  • Each daily entry includes a status indicating whether it has already been approved.

📘

Notes:

• Both endpoints require filtering by Employee ID(s), and Date or date range.
• Employee IDs can be retrieved using the People search API.
• Both endpoints support cursor-based pagination.

For more details, see the Attendance API reference guide.

The Hiring API enables developers to programmatically retrieve job ads from Bob and display them on external career pages. This update introduces new fields in the job ad payload that improve data accuracy and support more advanced filtering.

What's new

• Accurate job ad location: The Hiring API now exposes the correct job ad location through a new jobAdSite field. Previously, the API only returned the site associated with the job opening, which resulted in incorrect data for multi-location job ads. This fix ensures consistency with what candidates see on career pages.
• Workspace type: A new workspaceType field is now also exposed, allowing filtering job ads by work arrangement: Remote, Hybrid, or On-site, improving data granularity and personalization.

These updates improve the accuracy and usability of job ad data across public-facing platforms and integrations.

Public API updates

• New fields added to job ad responses:
  • /jobAd/jobAdSiteId: The ID of the site that is defined for the job ad itself.
  • /jobAd/jobAdSite: The name of the site defined on the job ad itself.
  • /jobAd/jobAdCountry: The country name of the site is defined on the job ad itself.
  • /jobAd/workspaceTypeId: The ID of the workspace type defined on the job ad (e.g., "remote", "hybrid", "on-site").
  • /jobAd/workspaceType: The name of the workspace type defined on the job ad (e.g., "Remote", "Hybrid", "On-site").
• Filtering and querying support:
  • Both jobAdSiteId and workspaceTypeId can now be used in filters when querying job ads.
• Updated schema and documentation:
  • Open API documentation has been updated with new field definitions and filtering options.

Action Items for developers

🚧

These changes are non-breaking and additive. However, developers are encouraged to switch to the new job ad-level properties for better accuracy when using multiple locations for ads.

If you use the Hiring API to power your external career site:

• Update any integration logic to use jobAdSite and jobAdSiteId instead of site for accurate job ad location.
• Leverage the workspaceType field to filter or display work arrangement types.
• Review the updated API documentation for full schema details and filter usage.
• Notify any third-party partners you work with who may be relying on job location data in your external career page.

For more details, see Hiring API.

What’s new

We added a new field, currentAssignment, to the response of Get the balance for a given employee.

This field indicates whether the employee is actively assigned to the policy type on the date the balance is requested. It aligns the Public API with the information already shown in the Bob UI.

Possible values:

• Assigned – The employee is actively assigned to the policy type on the requested date.
• Unassigned – The employee is not actively assigned to the policy type on the requested date. Balance values may still reflect amounts accrued while the employee was previously assigned.

Action items

✅ No action required.

• currentAssignment is a read-only, informational field.
• Existing balance calculations are unchanged.
• The change is additive and provided for awareness, in case you want to use this additional information from the Public API.

For more details, see Get the balance for a given employee.

What’s new

A new auditing Notes field was added to the check-in process in Bob, allowing you to add notes for each key result progress update when performing a check-in from the UI. This field complements the existing goal-level auditing comment.

What’s new in the Public API

• The Goals API now supports a new optional notes field at the key result level for goal key result progress updates auditing (check-ins).
• The goal-level comment field remains available and can be used to add audit notes for the overall goal progress.
• Both fields are stored in the check-in activity log only. They do not update the Goal or Key Result entities.
• comment and notes are not returned by search or metadata endpoints.

Affected endpoints

• Update Key Results Progress

Action items

✅ No action required. The new parameter is optional.

You can start using notes to add auditing context when updating the progress of key results.

To learn more and for usage details, see Update Key Results Progress.

What's new

The new Projects API in the Attendance module enables external systems to create, manage, and synchronize project data directly with Bob.

This API streamlines project-based time tracking by eliminating manual data entry, reducing redundancy, and enabling external project management systems to maintain Bob as the single source of truth for project time tracking.

Key capabilities

• Use the API to create, read, update, archive, and restore projects in Bob.
• Assign employees, tasks, and clients to projects programmatically.
• Billable and non-billable flags on projects and tasks help track invoicable time.
• Supports consistent, object-based structures aligned with Bob’s latest data model.

The API enhances accuracy in project tracking and enables scalable, automated integration with tools such as timesheet apps, project management systems, or billing platforms.

📘

Note: While you can manage projects and related metadata via the API, attendance entries must be entered through the Bob UI.

For full details, including permissions and example workflows, see Explore Attendance API.

For reference, see Projects API.

The Goals API now supports goal cycles, enabling the retrieval of cycles linked to goals and weights for performance reviews.

About goal cycles and performance review weights

A goal cycle lets admins define a timeframe and assign weights to each goal, helping teams clearly understand which objectives matter most.

A goal's weight for performance review directly influences overall performance scores for employees when included in the performance review.

This feature helps ensure that both managers and employees are aligned on what matters most and how it will be measured.

What's new

The Goals API has been extended to support goal cycle management, enabling external systems to assign goals to cycles and align with organizational time periods, such as quarterly or annual reviews.

New endpoints:

• Get Goal Cycle Metadata – returns cycle schema metadata
• Search Goal Cycles – retrieves available goal cycles (no filtering)

Enhanced endpoints:

• Create goal – now accepts an optional cycleId field to assign a goal to a cycle
• Update goal – supports assigning, moving, or unassigning goals from a cycle via cycleId
• Search for goals – now includes cycleId and read-only performance reviewweight in responses
• Goals metadata – includes metadata definitions for cycleId and performance review weight fields

Behavior highlights:

• Goals can be assigned to cycles using a valid cycleId
• To move a goal to a different cycle, send a new cycleId in the update payload
• To unassign a goal from a cycle, set cycleId to null
• Weight is a read-only field, used for performance reviews only (does not impact goal progress). This field cannot be set via the API.

Security & validation:

• Only cycles accessible to the authenticated service user’s company can be assigned
• Using invalid or unauthorized cycleId values return validation errors

To learn more, see Goals reference guide.

The effectiveDate field in the Work Table update API is now correctly enforced as mandatory, preventing silent failures or unexpected behavior.

What's new

We fixed a validation issue in the Work Table update endpoint where the effectiveDate field was mistakenly treated as optional. When the field was omitted, the API defaulted to the current date, which could result in a new row being created instead of updating the intended one, along with incorrect audit logs.

With this fix, effectiveDate is now correctly required for all update requests.

Why it matters

When effectiveDate wasn’t provided, the system used the current date by default.

This could lead to:

• An unexpected new Work Table row being created
• Updates being applied to the wrong entry
• Incorrect or misleading audit logs

Requiring effectiveDate ensures updates target the intended Work Table entry and behave predictably.

Best practice for updates

• Always read the existing Work Table entry first
• Modify only the fields that need updating
• Write the full entry back, keeping the same effectiveDate value

If you need to change the effective date, use the appropriate create or delete endpoints instead of an update.

Action required

Review your integrations to make sure all Work Table updates include the correct effectiveDate that preserves the original value.

To learn more, see Update a work entry in the employee's work history table.

Archived employee data table columns are now excluded from Public API responses unless specifically requested.

Why the change

Previously, employee table endpoints that fetch table data, such as the work table and other employee tables, used to include archived custom columns' data in their responses. This created confusion for developers who saw fields that do not exist for this table in the UI.

Now, all employee table data endpoints exclude archived columns by default. This makes responses cleaner and more intuitive, reducing the need to handle or filter out irrelevant fields when building or maintaining integrations.

What’s new

A new query parameter is now supported across all relevant employee table endpoints:

• Query param: includeArchived (boolean, default: false)

Description: This parameter is designed to maintain backward compatibility. By default (false) archive columns will not be returned. Developers who want to include them should set the flag to true.

Affected endpoints

Single employee endpoints:

• GET /people/{id}/work
• GET /people/{id}/employment
• GET /people/{id}/lifecycle
• GET /people/{id}/salaries
• GET /people/{id}/equities
• GET /people/{id}/variable
• GET /people/{id}/training

Bulk endpoints:

• GET /bulk/people/work
• GET /bulk/people/employment
• GET /bulk/people/lifecycle
• GET /bulk/people/salaries
• POST /people/actual-payments/search

✅ No action is required

No action is required unless your integration depends on data from archived columns. If you do need the archived columns, you should update your API calls to include:includeArchived=true