Reference · built on requestConnectorHR, scheduling & workforce

BambooHR

Employee records, time off requests, timesheets, and field-change webhooks from a BambooHR account through its REST API.

Request accessPricing ↗

About

BambooHR is an HR system for small and mid-sized companies. Its REST API lives at https://{companyDomain}.bamboohr.com/api/v1/ and covers employee records and tables, time off requests and policies, timesheets with clock and hour entries, datasets and reports, and applicant tracking. Webhooks fire on changes to employee fields, either global ones set in account settings or permissioned ones created through the API.

An operator on Fibric reads the employee roster, time off requests, and timesheets, and proposes an approval, a clock entry, or a correction for you to confirm. You get a receipt with each one: the change, the reason, and how to undo it.

This is a reference listing. It documents what Fibric would read from BambooHR 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 as a cursor-paginated roster through List Employees, with unreadable fields returned as null and named in _restrictedFields
  • Employees changed since a timestamp through GET /api/v1/employees/changed, marked Inserted, Updated, or Deleted
  • Time off requests in a date window through GET /api/v1/time_off/requests, filterable by status: requested, approved, denied, canceled, superceded
  • Timesheets by pay period through GET /api/v1/time-tracking/timesheets, with status OPEN, PENDING_APPROVAL, or APPROVED and total and overtime hours
  • Clock and hour entries for the last 365 days through GET /api/v1/time_tracking/timesheet_entries
  • Field-change webhooks signed with HMAC SHA-256, carrying X-BambooHR-Timestamp and X-BambooHR-Signature headers

Proposed actions

  • Target capability: propose approving a time off request through POST /api/v1/time-off/requests/{id}/approvals, completing the caller's step in the chain
  • Target capability: propose denying or canceling a time off request through the denials and cancellations resources
  • Target capability: propose clocking an employee in through POST /api/v1/time-tracking/clock-ins, which opens a clock entry
  • Target capability: propose creating or updating timesheet clock and hour entries
  • Target capability: propose a permissioned webhook on the fields an operator watches

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

What you can build

  • Approve routine leave without a manager's inbox

    Read requested time off, check it against coverage, and propose the approval step for the manager to confirm in one click.

    With Leave Conflict, Shift Coverage

  • Close every timesheet before payroll

    List timesheets still OPEN or PENDING_APPROVAL as the period ends and propose the sign-off or the missing entry.

    With Timesheet Signoff, Missed Punch

  • Start onboarding the moment a hire is saved

    Poll changed employee IDs, or watch the employment status field by webhook, then propose the first-day or last-day checklist.

    With Onboarding Checklist, Offboarding Sweep

Requirements

  • A BambooHR account and its company domain; requests go to https://{companyDomain}.bamboohr.com/api/v1/
  • An API key belonging to an enabled user whose permissions cover the employees, time off, and timesheets in scope
  • For timesheets, a user who can view the employees' timesheets; API access follows Time Tracking permissions
  • An HTTPS endpoint to receive webhook posts if you use field-change notifications
Authentication
An API key generated from the user's context menu in BambooHR, sent as the HTTP Basic username with any string as the password; each endpoint also lists the OAuth scope it requires.

Limits

  • BambooHR throttles requests it deems too frequent and returns 503 with a Retry-After header; no fixed rate figure is published
  • Timesheet entry queries reach back at most 365 days and are read in the company timezone; future pay periods are excluded
  • Webhooks watch employee fields and custom fields, not fields in custom tables, and a permissioned webhook stops if its creating user is deactivated
  • Repeated use of an unknown API key disables access for a period

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 BambooHR ↗

Questions and answers

How does BambooHR tell you an employee record changed?
Two ways. GET /api/v1/employees/changed returns the IDs changed since a timestamp, marked Inserted, Updated, or Deleted; a change to any field, employment status, job info, or compensation table counts. Webhooks post when monitored fields change, with retries up to five times at growing intervals.
What does approving a time off request through the API do?
POST /api/v1/time-off/requests/{id}/approvals completes the caller's step in the approval chain. The request stays in REQUESTED status while other approvals are outstanding, unless bypass is set to complete every remaining step. The older PUT status endpoint is deprecated.
Is there a documented rate limit?
No fixed number. The technical overview says requests can be throttled if BambooHR deems them too frequent, and a 503 response may carry a Retry-After header. An unknown API key used repeatedly is blocked for a period with a 403.
Ask about BambooHR

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 BambooHR 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