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.

We’ve updated our Rate Limiting article to include details on authorization-related WAF rules.

These infrastructure-level protections are triggered by repeated failed authentication or permission requests (e.g., HTTP 401 or 403) and are enforced by our Web Application Firewall (WAF). While separate from standard rate limits, they can affect integrations if not handled properly.

The article outlines what triggers a block, how long it lasts, and best practices to avoid it, helping developers build more resilient and compliant integrations.

To learn more, see Authorization-based blocking (WAF limits).

📘

Want to stay updated?
Subscribe to our changelog RSS feed to get notified when we update our documentation or release new features.