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:

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.

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.