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.

We’ve enhanced the Get the details of an existing time off request endpoint to support more precise tracking of time off usage. This will help you gain deeper insights into time off usage with per-day cost values and optional daily breakdowns in the response.

Responses now include a new cost field per day, showing the amount of time deducted from the employee’s balance for that day. This unlocks better visibility and control for payroll, reporting, and integration workflows.

To enable this daily view for multi-day requests, use the includeDailyBreakdown query parameter (default: true).

📌 What’s changed?

• All multi-day time off requests now include a durations array in the response payload when requested to include a daily breakdown/
• Each day includes a new cost field, indicating how much time is deducted per day
• New query parameter: includeDailyBreakdown (boolean, default true)
• Duration array is returned only when includeDailyBreakdown=true

📘

Notes:

• The cost field is additive to the existing totalCost field and enables more granular day-by-day tracking
• For single-day requests, the cost and totalCost will be the same
• The cost value is calculated according to the time off policy's unit (either days or hours) and excludes non-working days like weekends or holidays.

Affected endpoints

• Get the details of an existing time off request

The Attendance API has been extended to support full lifecycle management of project tasks.

What’s new

• Developers can now programmatically create, update, archive, and restore project tasks, enabling deeper integration with external project and time-tracking systems.
• Previously, the API exposed only project task metadata and search endpoints, limiting integrations to read-only access to project tasks.

New endpoints

• Create project task(s): Supports bulk creation of up to 100 tasks per request. Tasks are created as active by default.
• Update project task: Replaces the existing task record with the provided payload. The task status cannot be updated via this endpoint.
• Archive project task: Sets the task status to archived. Archived tasks remain queryable but cannot be selected for new attendance entries.
• Restore project task: Restores an archived task, making it available for attendance entry selection again.

Notes for developers

• ✅ No action required. These changes are non-breaking and additive.
• Task status (active or archived) is managed exclusively via the archive and restore endpoints.
• The update endpoint performs a full replacement of the task record, so existing task data should be retrieved before updating to avoid data loss.
• Bulk operations are supported for task creation, with a maximum of 100 tasks per request.

For full details, see Projects API.