We added new Hiring API search endpoints so you can retrieve additional candidate profile details and hiring workflow data (such as interviews, evaluations, and offers).

What changed

You can now retrieve additional core Hiring data from Bob via new Hiring API search endpoints, including:

• Candidate profile details (education, experience, languages, skills, volunteer experience)
• Hiring workflow artifacts (application form answers, interviews, evaluations, scorecard templates)
• Offers (including offer status, dates, etc.)

Why this matters

These new endpoints help you:

• Build richer hiring analytics and dashboards with more complete candidate profiles and pipeline data
• Reduce manual exports by integrating additional hiring data into downstream systems (for example, BI tools and internal reporting)

Notes

• This is an additive change and is backward compatible. No action is required.

Learn more

• Explore Hiring API
• Candidates endpoints
• Application endpoints
• Interviews and evaluations endpoints
• Offers endpoints

We added a new Time Off API endpoint so you can sync company calendar events (such as public holidays and company closures) from Bob to other tools.

What changed

You can now use Search calendar events to retrieve company-wide calendar events for a selected date range.

This endpoint helps you sync:

• Public holidays
• Company closures
• Other company calendar events available via the API

The response supports filtering by site and can also return events in the context of specific calendars.

Why this matters

This update helps you:

• Reduce manual maintenance by avoiding duplicate holiday lists in external systems
• Keep holiday and closure days consistent across tools (for example, calendars, scheduling tools, and reporting)
• Support multi-site organizations by syncing the right events for each site

Notes

• This is an additive change and is backward compatible. No action is required.
• You can use this alongside the Attendance Entries API when planning and reporting time with the right context for holidays and other company events.

Learn more

• Explore Time Off API
• Explore Attendance API
• Calendar events reference guide

The table.entry.created and table.entry.updated webhook events now return cleaner payloads (starting March 24, 2026). The row identifier fields are now included only when relevant to the table type.

What changed

• The id and effectiveDate fields are now optional and returned based on the table type.
• Historical tables: include effectiveDate as the row identifier.
• Non-historical tables: include id as the row identifier.
• Previously, both fields were always returned, with null values when not applicable.

Why this matters

• Consistency: Aligns with other webhook events that return context-specific data.
• Clearer contract: Payload structure reflects how entries are actually identified.
• Simpler handling: No need to handle null values for irrelevant identifiers.
• More robust parsing: Encourages handling payloads based on table type, not field presence.

Examples

Historical table (e.g. lifecycle, work)

  "companyId": 636192,
  "type": "table.entry.created",
  "triggeredBy": "3332883804594373380",
  "triggeredAt": "2025-01-08T13:06:26.915906",
  "version": "v2",
  "data": {
    "employeeId": "3332883854254932743",
    "tableId": "lifecycle",
    "effectiveDate": "2025-01-08"
  }
}

Non-historical table (e.g. bank accounts, custom table)

{
  "companyId": 636192,
  "type": "table.entry.created",
  "triggeredBy": "3332883804594373380",
  "triggeredAt": "2025-01-08T13:54:03.608759",
  "version": "v2",
  "data": {
    "employeeId": "3332883904477528858",
    "tableId": "bankAccounts",
    "id": 6236350
  }
}

Action required

🚧

Check your code compatibility

• No action required if your integration already handles identifiers based on table type.
• Update your logic if you assumed both id and effectiveDate are always present:
  • Do not rely on null values.
  • Use the table type to determine which identifier to expect.

Learn more

See schema and examples in:

• Table entry created webhook event
• Table entry updated webhook event

We’ve added support for bringing courses from an external learning content provider into Bob Learning, with course details and completion progress kept in sync.

What’s new

• Companies can connect an external learning content provider to Bob Learning using the Bob Learning API.
• You can ingest the provider’s course catalog into Bob and sync learner progress programmatically.

To learn more, see Explore Learning API.

Value

• Expands the learning content employees can access in Bob without switching between multiple systems.
• Enables consistent, accurate completion reporting in Bob even as the external course catalog evolves over time.
• Supports compliance and audit requirements by ensuring learner progress data is centralized and up to date in Bob.

Endpoints

• Create integration
• Delete integration (soft delete)
• Create training content (bulk insert)
• Update training content (bulk patch)
• Archive training content (bulk)
• Submit xAPI statement

Action required

• This is a new capability. No action is required unless you want to adopt it.
• To learn more, see Explore Learning API.

We added specialRateEligibleHours to attendance summaries and daily breakdown responses.

What changed

The specialRateEligibleHours field was added to the Public API to align with the new Attendance feature that supports special rates based on day of week (released as part of the April 2026 release).

Field details

• Represents hours eligible for premium pay on days covered by an attendance policy’s special day-of-week rate (for example, configured weekends or other off days).
• Relevant when a policy applies a special rate for specific days of the week.
• If the day is a bank holiday, bank holiday premium rules apply instead.

Affected endpoints

• Attendance summaries search endpoint
• Attendance daily breakdown search endpoint

Notes

• This is an additive change and is backward compatible. No action is required.

To learn more, see Attendance API.

What's new

You can now manage attendance entries end-to-end via the Bob Public API, including create, update, search, and delete operations. This also introduces dedicated clock-in / clock-out endpoints, enabling real-time, API-driven attendance flows (for example, kiosk or on-site check-in scenarios).

Why this matters

If your integration relies on Bob as the system of record for attendance, you can now:

• Create entries from an external system
• Update entries for corrections and completion (for example, add clock-out later)
• Fetch entry IDs via search, then update/delete reliably
• Associate entries with projects and tasks for project-based reporting
• Support real-time clock-in/out flows, such as kiosks, mobile apps, or physical terminals

Unlike standard entry creation, clock-in / clock-out endpoints are optimized for incremental, real-time updates. For example, a kiosk flow typically creates an entry at clock-in and completes it later at clock-out, rather than sending a full entry upfront.

Additionally, the API now supports timezone-aware attendance handling, ensuring entries are recorded and interpreted correctly across distributed teams and global workforces. This is especially important for integrations operating across multiple regions or syncing data from systems in different timezones.

New endpoints

• Fetch attendance entries
• Bulk create attendance entries
• Bulk update attendance entries for an employee
• Clock in (create entry)
• Clock out
• Delete an attendance entry

To learn more, see Explore Attendance API.

Action required

• This is a new capability. No action is required unless you want to adopt it.
• This expands on the existing Import punches endpoint (still supported), by enabling full lifecycle management of attendance entries, including clock in, clock out, and linking entries to projects (when policies allow).

What’s new

A new Hiring Public API is now available. You can retrieve core hiring data from Bob, including candidates, job openings, and applications, and use it in your own reports, integrations, and workflows.

Why this matters

Until now, the Public API mainly supported job ads (commonly used for external career pages). With Hiring core data endpoints, you can also work with the underlying hiring objects, which enables:

• More complete hiring reporting in BI tools and internal dashboards
• Easier data sync between Bob and third-party systems
• More flexible custom workflows without manual exports

New endpoints

This release introduces a new Hiring API surface that supports retrieving hiring data such as:

• Candidates
• Job openings
• Applications

To learn more, see Explore Hiring API .

Action required

• This is a new capability. No action is required unless you want to adopt it.
• To learn more, see Explore Hiring API .

To align with HiBob’s new Field Level Permissions (FLP) feature (currently in beta), the Employee Tables Public API now supports returning partial results when access to specific columns is restricted.

When this happens, endpoints may return null values for restricted columns. To make this explicit, we added response metadata + a lightweight response header to help you detect restricted columns and alert on missing permissions.

What changed

1. New response header: X-Has-Restricted-Columns

   GET endpoints now return: X-Has-Restricted-Columns: true when at least one column in the response was restricted.

2. New response field: restricted_columns

   Employee table response schemas now optionally include a restricted_columns object, which lists the columns that were restricted due to missing field level permission. The permission can be view or view history.

   Example:

{
	"values": [...],
	"restricted_columns": {
		"no_view_permission": ["salaryPayType", "fte"],
		"no_view_history_permission": ["department"]
	}
}

When you’ll see this

The new restricted_columns field and X-Has-Restricted-Columns header are returned only when:

• FLP is enabled for the company (currently this feature is in beta and not publicly available) and
• at least one column in the response is restricted for the service user.

If FLP is disabled, or if there are no restrictions, responses remain unchanged (no restricted_columns, no header).

Why this matters

This change helps API consumers:

• Distinguish between missing data vs. restricted data
• Understand which columns are blocked (and why)
• Set up monitoring/alerts when integrations are missing permissions
• Request the correct permissions from admins

Backward compatibility

This is an additive and backward-compatible change:

• Existing integrations won’t break.
• Integrations that want to detect partial results due to field level permissions can start checking restricted_columns and/or X-Has-Restricted-Columns.

To learn more, see Detecting restricted columns in API responses.

We reduced the rate limit for Goals search endpoints from 100 requests per minute to 40.

What changed

To improve overall service stability and ensure consistent performance for all tenants, the rate limit for the Goals search endpoints has been updated:

• Previous limit: 100
• New limit: 40

Affected endpoints

The updated rate limit applies to these Goals search endpoints:

• POST /v1/goals/goals/search
• POST /v1/goals/goals/key-results/search
• POST /v1/goals/goal-types/search
• POST /v1/goals/goal-cycles/search

What you need to do

If your integration makes frequent search calls, please ensure you:

• Handle HTTP 429 (Too Many Requests) responses.
• Follow Rate limiting best practices.
• Consider reducing polling frequency and batching queries where possible.

Webhook events are now documented directly in each module’s API Reference for a more structured, discoverable experience.

What’s changed

• Webhook events now appear as documented POST requests within each relevant module in the API Reference.
• Each event includes a structured payload schema with field-level details and applicable headers.
• We added more examples of employee data table event payloads for different table update scenarios, showing what each event payload looks like.
• Full JSON examples for all events are available via Examples → Payload Example.

Why this matters

• Easier discovery by locating webhook events alongside the rest of the module API.
• Clearer implementation with structured schemas instead of example-only documentation.
• More AI-friendly reference format, improving compatibility with coding assistants and automated tooling.

How does this affect you

No action is required. This is a documentation-only improvement.

Relevant reference pages

• Employee data webhook events
• Time off webhook events
• Tasks webhook events
• Docs webhook events
• Workforce Planning webhook events

For more details, see Getting started with webhooks.