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.

The Time off 'Who's out' API now supports filtering time off requests based on the policy's activity type.

What’s new:

A new includeWorkingRequests boolean query parameter has been added to the Who’s out API, where:

• true (default, backward-compatible with existing behavior): Includes all time off requests, including WFH, business travel, and other working-type policies (activity = workTime)
• false: Excludes working-type requests and returns only actual absences such as sick leave, holidays, or unpaid leave (activity = paidTimeoff or unpaidTimeoff)

To learn more about policy activity types, see Get Policy type details.

Why it matters:

• Lets you distinguish between true time off and remote or on-the-go work
• Reduces confusion in calendars, dashboards, and workflows that rely on absence data
• Supports more accurate availability tracking across teams
• Improves integration with tools that need a clear picture of who's fully out versus just working remotely

To learn more, see Read a list of who's out of the office.

We’ve improved documentation coverage for creating employees via the API to streamline employee creation.

What's new?

• Enhanced Create company employee endpoint documentation with 2 additional recommended input fields: work.title and work.department (non-mandatory), and better descriptions for fields allowed input values.
• A new Create an employee article outlining the employee creation flow with clearer links to metadata and permissions to reduce trial-and-error.

👍

Note: This is a documentation update only. There are no changes to the API’s behavior.

You can now fully manage positions and position openings in Bob through the Workforce Planning Public API. This release adds write capabilities, allowing you to automate position creation and updates directly from your external systems.

These additions, together with the webhooks introduced in the previous release, make it easier to sync Bob with your FP&A or ATS tools, react to position changes in real time, and streamline headcount planning and hiring workflows.

What's new

With the new endpoints, you can:

• Create and update positions with openings and a budget
• Create and update position openings
• Create and update position budgets
• Cancel positions
• Delete openings

ℹ️

Note: The write and update endpoints are designed using our new object-based structure and standardized API methodology, part of our broader effort to make Bob’s APIs more consistent, predictable, and easier to work with across different domains.

To learn more, see Explore Workforce Planning API.

Bob now supports requesting time off with different, specific hours for each day, improving flexibility for employees and delivering more accurate data for HR and payroll. This capability is now also available via the public API.

What’s new:

• The Time Off API now supports both creating and fetching requests with different hours and portions (all-day or vacant) per day
• Matches functionality already available in the app
• Supports multi-day requests with custom start/end times per day
• Example: 09:00–18:00 on Monday, 08:30–16:00 on Tuesday — all in one request

Why it matters:

• Aligns API functionality with real-world, flexible scheduling
• Enables precise time tracking for payroll and compliance
• Enhances integrations with dynamic scheduling and HR tools

To learn more, see Time off API.

You can now programmatically manage goals in Bob with the new Goals API, enabling full integration with external OKR and performance management systems.

Key capabilities include:

• Create, update, and delete goals: define objectives, assign owners, and track updates over time
• Manage goal hierarchies: align goals across the different goal levels
• Track key results: report on measurable outcomes and progress using flexible check-in workflows

The API follows Bob’s new object-based model, introducing consistent data structures and predictable references across endpoints.

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

For the reference guide, see Goals reference guide.

Following our recent enhancements to the documentation of Get the details of an existing time off request endpoint, we’ve now applied the same enhancement to three more endpoints:

• Get time off requests changes (timeoff/requests/changes)
• Read a list of who's out of the office (timeoff/whosout)
• Read a list of who's out of the office today or on the specified date (timeoff/outtoday)

Each now displays the correct response structure for each time-off type (days, hours, portion-on-range, etc.).

Note that each endpoint returns different levels of detail and data, so the schemas vary slightly between them. For example, the changes endpoint includes change metadata such as the change type and the original request ID.

To learn more about how to use the new format, see Get Time off request: now shows typed responses

👍

Note: This is a documentation-only change. There’s no impact on the API itself.

Bulk access to historical tables now aligns with permission-based rules, ensuring more accurate and secure data retrieval.

What’s new

Bulk API endpoints for historical employee data (Work, Salaries, Lifecycle, and Employment) now return results based on the specific permissions granted to the service user, enabling the retrieval of only the current row when applicable:

• If the user has only the "View selected employees' Work sections" permission, the API will return just the current active row.
• If the user has "View selected employees' Work section histories", it will return the complete history, including the current row.
• Users with both permissions will also receive the full dataset.

This logic is now consistent with how the single-entry endpoints behave.

Why this change

Previously, bulk endpoints required history permissions and always returned the full table, including past and current records. With this update, the bulk API now behaves like the single endpoints, offering a more consistent and predictable experience, and importantly, supporting use cases that require only the current active row.

This change gives teams more flexibility and control when working with employee data at scale.

To learn more, see Employee Table Endpoints.

What's new

The documentation page for Get the details of an existing time off request endpoint now displays all supported time-off request response types (e.g. days, hours, portion on range, etc.).

Each type has its own schema and its own example directly in the docs.

👍

Note: This is a documentation-only change. There’s no impact on the API itself.

Why this change

Previously, the response was documented as a single generic schema, making it unclear which fields apply to which request types. By documenting each variant separately, developers can immediately see what to expect for each type.

This change also supports the growing number of request types we’ve introduced to enable more flexible time tracking, and it will continue to evolve as we expand support.

How to use it

1. In the endpoint page, scroll down to the Responses section.
2. Use the per-type tabs to explore the different schemas and example payloads.
3. On the right-hand response tile, you can also choose the response example by type to see the exact structure.
4. In your code, continue to check the type property in the response to know which schema applies.