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

You can now schedule position cancellations via API.

What's new

You can now schedule or immediately cancel one or more positions using the new Schedule Positions cancellation endpoint in the Workforce Planning API.

Why this change

This completes the previously released feature that made the Cancelled soon status visible in API responses.

With this release, external systems can now set that status by scheduling cancellations in advance, making workforce transitions easier to plan and communicate.

How it works

• The endpoint receives a list of position IDs and optionally a cancellation date.
• If a future cancellation date is provided, the position will immediately display as Cancelled soon until it transitions to Cancelled at midnight on the selected date.
• If no date is provided, the cancellation will happen immediately.
• Any failure to cancel a position from the list will result in the entire transaction failing.
• If the position is currently filled, it will automatically unassign employees linked to any openings before completing the cancellation, extending the existing Cancel Position endpoint, which will fail in such a scenario.

To learn more, see: Schedule Positions cancellation

The Time off module in Bob now respects a new permission for viewing attachments in time off requests:

People's Data > Time off > Requests > View, download, and edit attachments

Previously, having only the permission Create, edit all fields, and cancel people's requests that haven't been approved yet was enough to access attachments via Bob and via the Public API. Now, only users and service users who have the new permission will have access to the attachment.

This new permission helps meet privacy and compliance requirements (e.g., for US regulations), keeps sensitive data like doctors’ notes secure, and allows managers to approve time off without seeing private documentation

What’s new in the Public API

To align with this new permission, the following endpoint has been updated:

• Get the details of an existing time off request - it now checks for this new permission before returning any attached files.

If a service user lacks this permission, attachment details will be masked in the response like this:

"attachmentLinks": [
  {
    "name": "******",
    "url": "******",
    "mimeType": "******"
  }
]

⚠️ Action required

If your integration relies on access to attachments, make sure to grant your service user's permission group the following permission: People’s data > Time off > Requests > View, download, and edit attachments.

To learn more, see Time off required permissions.

A new position status Cancelled soon has been added to the position workflow.

The Positions API now reflects this change and may return a cancelledSoon status for positions scheduled for future cancellation. This improves visibility into the termination process by signaling that a position is set to be cancelled soon, helping teams avoid unintended edits or reassignments.

Previously, positions marked for future cancellation were set to Vacant, and the cancellation occurred automatically on the scheduled date. Now, when a position is scheduled for cancellation via the termination flow in Bob, it will immediately show as Cancelled soon, and will automatically change to Cancelled on the termination date.

🚧

Note: The Cancelled soon status can only be set through the termination flow in Bob at the moment.

To learn more, see Explore Workforce planning API.