Reference · built on requestConnectorHR, scheduling & workforce

HiBob

People profiles, time off requests, attendance entries, and event webhooks from Bob, HiBob's HR platform, through its REST API.

Request accessPricing ↗

About

Bob is HiBob's HR platform. Its API is organized by module: Employee data (people, metadata, employee tables, custom tables), Time off (requests, balances, policies), Attendance (entries, clock in and out, daily breakdowns, projects), Tasks, Docs, Goals, Reports, Job catalog, Workforce planning, and Hiring. Customer integrations authenticate as an API service user, and webhooks v2 deliver employee, time off, task, document, and workforce planning events.

An operator on Fibric reads people, time off, and attendance, and proposes a time off request, an attendance entry, or a task for you to approve. Each proposal leaves a receipt with the change, the reason, and the undo.

This is a reference listing. It documents what Fibric would read from HiBob and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Employees through Search for employees and Read company employee fields by employee ID, within the fields the service user may view
  • Employee tables: work, employment, lifecycle, and salary history, plus company-defined custom tables
  • Time off requests, request changes since a point in time, and who is out today or on a date, subject to policy visibility
  • Time off balances and the policies behind them
  • Attendance entries, summaries, and daily breakdowns, searchable per employee and date
  • Webhook v2 events: employee.created, employee.updated, table.entry.created, timeoff.request.requested, timeoff.request.approved, and their siblings

Proposed actions

  • Target capability: propose submitting a time off request for an employee, or cancelling one
  • Target capability: propose attendance entries, created in bulk or as a clock-in and clock-out pair
  • Target capability: propose a task for an employee through the Tasks API
  • Target capability: propose a work or employment table entry for an employee

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Approve time off with coverage in view

    Receive timeoff.request.requested, pull the request, check who else is out that day, and propose the approval or a counter-date for the manager.

    With Leave Conflict, Shift Coverage

  • Match clocked hours to the plan

    Search attendance entries and daily breakdowns against scheduled hours and propose the correction or the sign-off.

    With Punch Match, Timesheet Signoff

  • Turn a lifecycle change into a checklist

    Act on employee lifecycle events, joined, terminated, or on leave, by proposing the onboarding or offboarding steps and the tasks that go with them.

    With Onboarding Checklist, Offboarding Sweep

Requirements

  • A Bob account and a Bob Admin to create the API service user, which cannot log in and starts with no permissions
  • A permission group holding the service user, with View on the root, about, employment, and work categories for basic people data
  • People's data > Time attendance > Manage time attendance sheets for the attendance endpoints
  • Permission to view private time off policies if requests under them must be visible
Authentication
HTTP Basic authentication with an API service user's ID and token, Base64-encoded as SERVICE-USER-ID:TOKEN; apps distributed through the Bob marketplace use OAuth 2.0 instead.

Limits

  • Rate limits are set per endpoint per minute, for example Search for employees 50, Submit a time off request 20, Import attendance data 5
  • People search has no pagination; large companies batch by employee ID on the client side
  • Requests under a Private policy are invisible without permission, and a Custom name policy shows its label instead of the type
  • Deleting a table entry sends no webhook, and the Training, Equity, Positions, and Jobs tables do not trigger table events

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request HiBob ↗

Questions and answers

What is an API service user in Bob?
An identity that exists only to authenticate API requests. It is not tied to an employee and cannot log in. It has no permissions until a Bob Admin adds it to a permission group, so each service user carries only the access its integration needs.
How do Bob webhooks v2 retry?
For up to 3 days with exponential backoff. A delivery counts as failed on an error status or when the endpoint takes longer than 10 seconds. Failures show on the webhooks page and email Bob Admins. The v2 payload carries version, type, triggeredBy, triggeredAt, and a data section with the entity id.
What are the rate limits?
They are set per endpoint per minute and returned in X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers. Examples: Search for employees 50, Create company employee 10, Fetch attendance summaries 100, Get time off request changes 50. Exceeding one returns 429.
Ask about HiBob

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with HiBob through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy