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.

Previously, the employee.deleted webhook event included only the employee ID, assuming the ID could be used to retrieve additional employee details if needed.

However, since the employee record is no longer available once deleted, it wasn't possible to retrieve any other data via the API. To solve this, we've added the employee's work email address to the employee.deleted event payload.

This allows you to retain a reference to the deleted employee even if the rest of their data is no longer accessible.

To learn more, see employee webhook events.

As part of our rollout of open-ended time off requests, we’ve introduced a new webhook event to support tracking when an end date is set. Open-ended requests enable employees to submit time off without specifying a return date, providing more flexibility for situations such as extended leave or unexpected absences.

To support this feature, the new timeoff.request.setEndDate webhook event (supported for webhooks v2 only) notifies your systems the moment an end date is added, either manually by the employee or automatically by the system (set automatically due to a scheduling conflict).

This capability enhances automation, improves data accuracy, and ensures that key updates are never missed as you adapt to more flexible leave policies.

To learn more, see Time off webhook events.

You can now subscribe to webhook events for positions, position openings, and budgets in Workforce Planning to receive real-time alerts whenever key changes occur.

Whether a new position is created, an opening is added, or a budget is updated, Bob will immediately notify your external systems, such as your ATS or FP&A platform, so you can stay in sync without manual updates or delays.

What’s included:

• Position events: get notified when a new position is created or updated
• Position opening events – get notified when a position opening is created or updated
• Position budgets events – get notified when a budget is created or updated

To learn more, see Workforce planning events.

HiBob now supports MCP.

🚧

This feature is currently in beta and may change as we continue to improve it.

You can now connect agents like Claude desktop, Cursor, Microsoft Copilot Studio, and Visual Studio Code to Bob using the HiBob MCP server, giving them access to:

• Read and update employee data
• Access time off records
• Retrieve and manage tasks

If you’re already working with MCP, you know the drill - just add the HiBob server and go.

To learn more, see Hibob MCP integration (Beta) or watch a demo on Introducing HiBob’s MCP.

What's new?

As our time off request capabilities evolve, we've enhanced the GET Time off request by ID endpoint with improved field descriptions to better reflect the values that may be returned when retrieving a time off request.

These are documentation-only changes, with no impact on the actual API behavior. The goal is to better reflect the structure and values already returned in the response payload.

What's included

• Updated category title: The API category name has changed from Time & Attendance API to Time Off & Attendance API for clarity.
• Additional request types: The requestType field now reflects the wider range of values supporting more flexible time off options:
  • days: The request spans X full days.
  • hours: The request is for X hours during the day (applies only to policies measured in hours).
  • portionOnRange: The request is for every morning or afternoon during the selected date range.
  • hoursOnRange: The request is for X hours each day in the date range.
  • differentDayDurations: The request is for a different number of hours on each day in the range.
  • specificHoursDayDurations: The request is for specific hours per day.
  • percentageOnRange: The request is for X% of each day in the date range.
• New durations field: Added a durations array to reflect granular time off requests that vary across the selected days.

To learn more, see Get the details of an existing time off request.

Employee Data API now supports the new Job Catalog 2.0 ↗.

What's new?

The Employee Data API now reflects the structure of the new Job Catalog 2.0, where employees are linked to job profiles instead of job levels.

When retrieving an employee's job via the API:

• employee.jobProfileId:
  • New field that returns the identifier of the job profile assigned to the employee.
  • Available only for customers using Job Catalog 2.0 ↗.
  • Use it to fetch full job details via the Job Catalog API.
• employee.jobLevelId:
  • Previously returned the job from the old job catalog.
  • For customers on Job Catalog 2.0, this now actually returns the new job profile ID.
  • ⚠️ This field will be deprecated in the future. Update your integrations to use jobProfile.

To learn more, see Employee data access.

Who does this affect?

This change applies to any customer using the Job Catalog 2.0 in case:

• You did not use the old Job Catalog before February 9, 2025, or
• You've upgraded from the old catalog to version 2.0.

To learn more, see Getting started with the new job catalog ↗.

Upgrade notes

If you've upgraded to the Job Catalog 2.0 ↗:

• The employee.jobLevelId now returns the job profile id.
• The full job profile data includes level, title, and additional metadata.
• The human-readable value remains familiar: e.g., "Lead (3) Account Executive (J-6329338628)"
• The employee.jobLevelId field continues to work for now, but should be replaced with jobProfileId in your code.

🚧

Deprecation note:

The employee.jobLevelId field will be deprecated in the future. We recommend switching to jobProfileId in your integrations as soon as possible.

We’ve removed the get-employee header from employee webhooks payload.

This header included a direct link to the now-deprecated GET Employee API and is no longer relevant for current integrations.

It was originally added to help customers retrieve full employee data, but going forward, the employee search endpoints should be used instead.

Why this change?

This update ensures webhook payloads reflect supported and scalable API usage. All related references have been removed from our documentation to avoid confusion..

Who is affected?

Any systems relying on this header should be updated to use the search endpoints to retrieve employee data.