OVERALL CONTROL / 0.6-customer-control
Grades and scoring
Data access
25% of the overall score before applicability adjustment.
Scored answers and evidence
Read interface 7.5/10
Structured API for the declared product scope
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
People search returns permitted current employee fields. showInactive and population grants determine whether former employees are included.
HiBob people read API contract ↗
POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current values · Checked 2026-10-16
Bulk delivery 8.8/10
Batched or iterable API requests
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
People search returns every matching accessible employee in one unpaginated response. Use a lightweight ID discovery then permitted field batches if needed; showInactive defaults false.
HiBob people read API contract ↗
POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current values · Checked 2026-10-16
Query expressiveness 8.8/10
Documented structured API filters
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
Search supports root.id/root.email equality selection and explicit fields; arbitrary joined queries and employee-table history are outside this contract.
HiBob people read API contract ↗
POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current values · Checked 2026-10-16
Access cost barrier -
-
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
Lowest-paid-plan entitlement and complete fixed API or partner access fees are unresolved.
HiBob API service users ↗
Create service user; ID/token; permission groups; no default access; employee population · Checked 2026-10-16
Third-party accessibility
20% of the overall score before applicability adjustment.
Scored answers and evidence
Third-party eligibility 10.0/10
Customer authorization without discretionary provider approval
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
The transition guide permits custom integrations developed in-house or by non-formal vendors using customer service users. Approved partner OAuth is a separate distribution route.
HiBob service-user integration transition ↗
Custom integrations developed by non-formal vendors or in-house must use service users · Checked 2026-10-16
HiBob API service users ↗
Create service user; ID/token; permission groups; no default access; employee population · Checked 2026-10-16
Downstream permission -
-
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
The operation guides do not establish applicable downstream processing, AI-use or redistribution rights.
HiBob API service users ↗
Create service user; ID/token; permission groups; no default access; employee population · Checked 2026-10-16
External action
15% of the overall score before applicability adjustment.
Scored answers and evidence
Write interface 7.5/10
Create and update in one business domain
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
POST /v1/people creates employees and PUT /v1/people/{identifier} updates profile fields. Field permissions apply; history-table changes require separate operations.
HiBob create employee ↗
POST /v1/people; required fields and create permissions · Checked 2026-10-16
HiBob update employee profile ↗
PUT /v1/people/{identifier}; partial updates; tables excluded; read freshness · Checked 2026-10-16
Custom application path 10.0/10
Customer applications using fixed APIs without provider selection
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
The documented customer credential route supports the scoped custom integration.
HiBob service-user integration transition ↗
Custom integrations developed by non-formal vendors or in-house must use service users · Checked 2026-10-16
HiBob API service users ↗
Create service user; ID/token; permission groups; no default access; employee population · Checked 2026-10-16
Continuity
15% of the overall score before applicability adjustment.
Scored answers and evidence
Refresh mechanism 7.5/10
Documented updated-since filters or webhooks
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
Use employee created/updated/deleted event hints and repeat full people search; no general profile updated-since filter is established.
HiBob employee-data webhook contract ↗
Employee created/updated/deleted; explicit field changes; deleted ID/email; table exclusions · Checked 2026-10-16
HiBob people read API contract ↗
POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current values · Checked 2026-10-16
Limit visibility 10.0/10
Published numeric quotas and recovery instructions
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
People search allows 50 requests/minute. Follow endpoint-specific rate headers and reset time on 429; authentication failures can trigger separate WAF blocks.
HiBob endpoint limits and recovery ↗
People search 50 requests/min; 429; X-RateLimit headers; WAF auth-failure blocks · Checked 2026-10-16
CDC and deletion capture 7.5/10
Updates and deletion identities documented for the stated resources
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
Profile webhooks identify updates and deleted employee ID/email. Calculated fields and unsupported table changes are excluded; periodically reconcile the selected population.
HiBob employee-data webhook contract ↗
Employee created/updated/deleted; explicit field changes; deleted ID/email; table exclusions · Checked 2026-10-16
Replay and gap recovery 2.5/10
Rebuild from a fresh snapshot; no historical replay established
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
A fresh people search returns the complete matching permitted array without pagination or truncation. It rebuilds current profiles, not deleted payloads or history-table state.
HiBob people read API contract ↗
POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current values · Checked 2026-10-16
Data exit
20% of the overall score before applicability adjustment.
Scored answers and evidence
Export custody 7.5/10
Customer-held structured files or API records
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
Permitted structured API records can form a customer-held copy.
HiBob people read API contract ↗
POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current values · Checked 2026-10-16
Post-cancellation access Disclosure
-
Disclosure only; does not reduce planned-exit credit.
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
Live retrieval does not establish contractual access after cancellation.
HiBob people read API contract ↗
POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current values · Checked 2026-10-16
Planned migration fidelity 7.5/10
Portable structured records on documented routes; whole-product completeness unverified
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
The declared current record collection is portable; full history, files, configuration and whole-product reconstruction are unverified.
HiBob people read API contract ↗
POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current values · Checked 2026-10-16
Business logic and customization
5% of the overall score before applicability adjustment.
Scored answers and evidence
Logic authoring 2.5/10
External integration code; native business logic portability not established
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
The documented route supports external integration code; native workflow authoring and portability are unverified (API clients are separate artifacts).
HiBob API service users ↗
Create service user; ID/token; permission groups; no default access; employee population · Checked 2026-10-16
Rights to custom logic -
-
HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate.
Rights to reusable native workflow definitions and independent execution are unresolved.
HiBob API service users ↗
Create service user; ID/token; permission groups; no default access; employee population · Checked 2026-10-16
Scores are out of 10. * Incomplete evidence discounts verified capabilities (unknown answers stay unknown). Planned migration drives data exit. Scoring method ↗
CUSTOMER CHOICE
Third-party accessibility
The transition guide permits custom integrations developed in-house or by non-formal vendors using customer service users. Approved partner OAuth is a separate distribution route.
Confirm who can connect, who owns the credentials and which uses are permitted. Customer consent and provider approval can be separate requirements; the selected plan and contract still matter.
READ / INTEGRATE
API and export routes
People search returns permitted current employee fields. showInactive and population grants determine whether former employees are included. People search returns every matching accessible employee in one unpaginated response. Use a lightweight ID discovery then permitted field batches if needed; showInactive defaults false. Search supports root.id/root.email equality selection and explicit fields; arbitrary joined queries and employee-table history are outside this contract.
| Access route | Authentication | Credential owner | Provider approval | Access requirement | Last checked |
|---|---|---|---|---|---|
| Customer-managed Bob service user | HTTP Basic | Customer | No | customer authorization | 2026-10-16 |
Availability depends on your product, plan and agreement. See the documentation below for the requirements of each route.
ECONOMIC ACCESS
Cost, authentication and limits
Lowest-paid-plan entitlement and complete fixed API or partner access fees are unresolved.
Check API entitlement, credential ownership and rate limits for the route you intend to use. Include review fees, customer-plan upgrades and ongoing access charges in the total.
ACT FROM OUTSIDE
External action
POST /v1/people creates employees and PUT /v1/people/{identifier} updates profile fields. Field permissions apply; history-table changes require separate operations.
Validate the supported operation, acting identity and permission scope (read access does not imply write permission). Ambiguous retries and revoked credentials also affect whether an external workflow can run safely.
KEEP ACCESS USEFUL
Continuity
Use employee created/updated/deleted event hints and repeat full people search; no general profile updated-since filter is established. Profile webhooks identify updates and deleted employee ID/email. Calculated fields and unsupported table changes are excluded; periodically reconcile the selected population. A fresh people search returns the complete matching permitted array without pagination or truncation. It rebuilds current profiles, not deleted payloads or history-table state. People search allows 50 requests/minute. Follow endpoint-specific rate headers and reset time on 429; authentication failures can trigger separate WAF blocks.
CDC, deletions and recovery
| Question | Answer / applicable route | Evidence |
|---|---|---|
| Can ongoing extraction identify updates and deleted records on the declared route? | Updates and deletion identities documented for the stated resourcesHiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. Profile webhooks identify updates and deleted employee ID/email. Calculated fields and unsupported table changes are excluded; periodically reconcile the selected population. | HiBob employee-data webhook contract ↗Employee created/updated/deleted; explicit field changes; deleted ID/email; table exclusionsChecked 2026-10-16 |
| How can extraction recover after missed events or an interrupted consumer? | Rebuild from a fresh snapshot; no historical replay establishedHiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. A fresh people search returns the complete matching permitted array without pagination or truncation. It rebuilds current profiles, not deleted payloads or history-table state. | HiBob people read API contract ↗POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current valuesChecked 2026-10-16 |
Useful ongoing access includes corrections and deletions, not only the first export. A failed request, changed filter or lost resource permission should not be interpreted as a deleted record.
LEAVE WITH YOUR DATA
Data exit and portability
The declared current record collection is portable; full history, files, configuration and whole-product reconstruction are unverified. Live retrieval does not establish contractual access after cancellation.
Test the output against the destination’s required fields and history. Check stable identifiers, relationships, attachments and extraction time; a sample file proves only the coverage of that sample.
BUILD / INSPECT / REUSE
Business logic and customization
The documented route supports external integration code; native workflow authoring and portability are unverified (API clients are separate artifacts). Rights to reusable native workflow definitions and independent execution are unresolved.
Custom API access, ownership of workflows and the right to export their definitions are separate questions. A custom-app capability alone does not establish that business rules can move to another system.
AGREEMENTS / API DOCS / PROGRAM REQUIREMENTS
Documented conditions
Answers below come from public provider materials. Every answer retains its source check date, scope (a partner agreement does not describe every customer route). Customer contracts and live behavior still need verification.
| Question | Answer / applicable route | Evidence |
|---|---|---|
| What structured read interface is documented? | Structured API for the declared product scopeHiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. People search returns permitted current employee fields. showInactive and population grants determine whether former employees are included. | HiBob people read API contract ↗POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current valuesChecked 2026-10-16 |
| How can customers retrieve data in bulk? | Batched or iterable API requestsHiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. People search returns every matching accessible employee in one unpaginated response. Use a lightweight ID discovery then permitted field batches if needed; showInactive defaults false. | HiBob people read API contract ↗POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current valuesChecked 2026-10-16 |
| What queries can a customer issue outside the provider UI? | Documented structured API filtersHiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. Search supports root.id/root.email equality selection and explicit fields; arbitrary joined queries and employee-table history are outside this contract. | HiBob people read API contract ↗POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current valuesChecked 2026-10-16 |
| Who decides whether a chosen third party may connect? | Customer authorization without discretionary provider approvalHiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. The transition guide permits custom integrations developed in-house or by non-formal vendors using customer service users. Approved partner OAuth is a separate distribution route. | HiBob service-user integration transition ↗Custom integrations developed by non-formal vendors or in-house must use service usersChecked 2026-10-16 HiBob API service users ↗Create service user; ID/token; permission groups; no default access; employee populationChecked 2026-10-16 |
| What extra commercial condition applies to the routes supplying the assessed read capability, relative to the lowest paid plan? | -HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. Lowest-paid-plan entitlement and complete fixed API or partner access fees are unresolved. | HiBob API service users ↗Create service user; ID/token; permission groups; no default access; employee populationChecked 2026-10-16 |
| What permission is needed for the documented downstream use? | -HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. The operation guides do not establish applicable downstream processing, AI-use or redistribution rights. | HiBob API service users ↗Create service user; ID/token; permission groups; no default access; employee populationChecked 2026-10-16 |
| Which external write operations are documented? | Create and update in one business domainHiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. POST /v1/people creates employees and PUT /v1/people/{identifier} updates profile fields. Field permissions apply; history-table changes require separate operations. | HiBob create employee ↗POST /v1/people; required fields and create permissionsChecked 2026-10-16 HiBob update employee profile ↗PUT /v1/people/{identifier}; partial updates; tables excluded; read freshnessChecked 2026-10-16 |
| How can customers connect an application they build or choose? | Customer applications using fixed APIs without provider selectionHiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. The documented customer credential route supports the scoped custom integration. | HiBob service-user integration transition ↗Custom integrations developed by non-formal vendors or in-house must use service usersChecked 2026-10-16 HiBob API service users ↗Create service user; ID/token; permission groups; no default access; employee populationChecked 2026-10-16 |
| What mechanism supports repeatable extraction of changes? | Documented updated-since filters or webhooksHiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. Use employee created/updated/deleted event hints and repeat full people search; no general profile updated-since filter is established. | HiBob employee-data webhook contract ↗Employee created/updated/deleted; explicit field changes; deleted ID/email; table exclusionsChecked 2026-10-16 HiBob people read API contract ↗POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current valuesChecked 2026-10-16 |
| How are integration limits disclosed? | Published numeric quotas and recovery instructionsHiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. People search allows 50 requests/minute. Follow endpoint-specific rate headers and reset time on 429; authentication failures can trigger separate WAF blocks. | HiBob endpoint limits and recovery ↗People search 50 requests/min; 429; X-RateLimit headers; WAF auth-failure blocksChecked 2026-10-16 |
| Where can a usable data copy be delivered? | Customer-held structured files or API recordsHiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. Permitted structured API records can form a customer-held copy. | HiBob people read API contract ↗POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current valuesChecked 2026-10-16 |
| What retrieval rights are documented at cancellation? | -HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. Live retrieval does not establish contractual access after cancellation. | HiBob people read API contract ↗POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current valuesChecked 2026-10-16 |
| How can customers define their own business logic? | External integration code; native business logic portability not establishedHiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. The documented route supports external integration code; native workflow authoring and portability are unverified (API clients are separate artifacts). | HiBob API service users ↗Create service user; ID/token; permission groups; no default access; employee populationChecked 2026-10-16 |
| What rights or portability are documented for custom workflow artifacts? | -HiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. Rights to reusable native workflow definitions and independent execution are unresolved. | HiBob API service users ↗Create service user; ID/token; permission groups; no default access; employee populationChecked 2026-10-16 |
| What usable data or native definitions can leave before cancellation? | Portable structured records on documented routes; whole-product completeness unverifiedHiBob / current employee profile fields through customer-managed service users, including inactive people when explicitly selected and permitted. Employee history tables, payroll, time off and productized partner OAuth are separate. The declared current record collection is portable; full history, files, configuration and whole-product reconstruction are unverified. | HiBob people read API contract ↗POST /v1/people/search; full unpaginated matching array; showInactive; root.id/root.email; field permissions; current valuesChecked 2026-10-16 |
SOURCES / SCOPE / HISTORY
Sources and open questions
This review is based on the documentation below. Live account behavior and customer-specific agreements haven’t been tested.
Still to confirm
- Complete lowest-plan entitlement and fixed API fees
- Applicable downstream processing, AI-use and redistribution rights
- Contractual post-cancellation retrieval terms
- Native workflow artifact ownership, reusable export and independent execution
Documentation
Assessment checked 2026-10-16. Each answer retains its source and applicable route; the check date does not establish live account behavior.