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.

The Read avatar for an employee ID (v1/avatars/{employeeId}), and Read avatar for an employee email (v1/avatars) endpoints now enforces permission checks.

Background

Previously, service users could access employee profile pictures without being assigned to any permission group.

What this change?

Moving forward, visibility of avatars through the API is restricted based on the About category permission, aligning it with other employee data access rules.

To allow the service user to read the avatar, you now need to enable the permission:

  • People's data > About > View selected employees' About sections.

Workforce Planning API now supports the new Job Catalog 2.0.

What's new?

The Workforce Planning API now reflects the structure of the new Job Catalog 2.0, where positions are linked to job profiles instead of job levels.

When retrieving a position's job via the API:

  • /position/jobProfile:
    • New field that returns the job profile assigned to the position.
    • Available only for customers using Job Catalog 2.0.
    • Use it to fetch full job details via the Job Catalog API.
  • /position/job:
    • Previously returned a job level.
    • For customers on Job Catalog 2.0, this now returns the job profile for backward compatibility.
    • ⚠️ This field will be deprecated in the future. Update your integrations to use jobProfile.

To learn more, see Read company positions.

Who does this affect?

This change applies to any customer using Job Catalog 2.0:

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

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

Migration notes

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

  • The job level previously stored in /position/job now returns the job profile.
  • The job profile includes level, title, and additional metadata.
  • The human-readable label remains familiar: e.g., "Lead (3) Account Executive (J-6329338628)"
  • The /position/job field continues to work for now, but should be replaced with jobProfile in your code.
🚧

Deprecation note:

The /position/job field will be deprecated in the future. We recommend switching to jobProfile in your integrations as soon as possible.

Workforce Planning now supports prorated position costs. When you define your fiscal year and add an end date to a position, the platform automatically calculates the cost based on how long the position is active during that financial cycle.

You can now access these details through the Public API:

  • The /position/endEffectiveDate field is available on the position object. It indicates when the position’s cost should stop being included in planning.
  • The /position/positionBudget/proRatedCostCurrencyValue field is available on the position budget. It shows the calculated prorated cost of the position, converted to your company’s base currency.

This gives you API visibility into how position costs are prorated, helping you align external reports or tools with your workforce planning data.

To learn more, see Read company positions, and Read company position budgets.

We’re experimenting with short audio recaps and deep dives to make our documentation more accessible. The first ones are live at the end of the article:

Each provides a quick, AI-generated summary that highlights the main points.

We're curious if this format is useful to you, so feel free to share feedback via the vote option at the bottom of the article (and please include your email so we can follow up!).

Following past deprecation announcements:

These are now being completely shut down.

❗️

Final Notice: API Get Endpoints Shutdown by May 6, 2025

The Get endpoints listed below will be completely shut off by May 6, 2025.

  • GET api.hibob.com/v1/people
  • GET api.hibob.com/v1/people/XXXX

If your organization is still using the deprecated endpoints, action is required to prevent disruptions. Any processes relying on these endpoints will stop working, potentially impacting your operations. Follow the instructions below to migrate to the new Search API to replace the two GET endpoints.

❗️

Final Notice: API Access Tokens Shutdown by May 6, 2025

The "API Access Token" authentication method will be completly shut off by May 6, 2025.

Companies using this legacy method should transition to the Service User method immediately. From this date, API integrations using API Access Tokens will stop working. Any system or process that relies on API Access Tokens will fail, potentially causing disruptions.

Follow the instructions to transition to the API Service Users authentication method.