When the underlying HRIS is Bamboo HR, a Timesheet Entry can be created using a payload like:
```json theme={null}
{
"employee": "019ab506-66a2-7f6e-b8da-09d3579a534e",
"date": "2025-11-24",
"start_time": "2025-11-24T08:00:00Z",
"end_time": "2025-11-24T17:00:00Z"
}
```
When the underlying HRIS is Personio, a Timesheet Entry can be created using a payload like:
```json theme={null}
{
"employee": "0198e59a-876f-748c-8e38-c56e6246f8aa",
"break": 8,
"date": "2025-08-04T08:00:00Z",
"start_time": "2025-08-04T08:00:00Z",
"end_time": "2025-08-04T16:00:00Z"
}
```
When the underlying HRIS is Xero, a Timesheet Entry can be created using a payload like:
```json theme={null}
{
"employee": "0198e59a-876f-748c-8e38-c56e6246f8aa",
"start_time": "2025-08-04T08:00:00Z",
"end_time": "2025-08-04T16:00:00Z"
}
```
When the underlying HRIS is QuickBooks, a Timesheet Entry can be created using a payload like:
```json theme={null}
{
"employee": "0198e59a-876f-748c-8e38-c56e6246f8aa",
"hours_worked": 8,
"date": "2025-08-04T08:00:00Z",
"start_time": "2025-08-04T08:00:00Z",
"end_time": "2025-08-04T16:00:00Z"
}
```
When the underlying HRIS is Workday, a Timesheet Entry can be created using a payload like:
```json theme={null}
{
"employee": "019d29f5-07cf-7396-9ae1-34e5b71ad42c",
"date": "2026-03-26",
"hours_worked": 7.5,
"start_time": "2026-03-26T10:00:00Z",
"end_time": "2026-03-26T17:30:00Z",
"additional_attributes": {
"worker_time_block_id": "TEST_BB",
"time_entry_code_reference_wid": "c20c857a8cf41001aa4db119cb360000",
"out_reason_reference_id": "Out"
}
}
```
Workday-specific requirements:
-
out\_reason\_reference\_id must be one of: Break, Meal, or Out.
-
For
time\_entry\_code\_reference\_wid, search for All Time Entry Codes in the Workday portal and use the WID of any suitable code from the displayed list.
-
The selected Time Entry Code must have Units = Hours.
-
If the selected Time Entry Code has Entry Method = In/Out Only,
out\_reason\_reference\_id is required.
-
If the selected Time Entry Code has Entry Method = Hours Only,
out\_reason\_reference\_id must not be passed.
Use the Get Create Timesheet Meta endpoint to retrieve the required schema and values.
Contact Bindbee Support Team for additional details.
Contact Bindbee Support Team for additional details.
# Get Create Timesheet Meta
Source: https://docs.bindbee.dev/hris/timesheet-entries/get-create-timesheet-meta
get /api/hris/v1/timesheet-entry/meta/post
Returns request schema for POST Timesheet entry request.
# Get Timesheet By Id
Source: https://docs.bindbee.dev/hris/timesheet-entries/get-timesheet-entries-by-id
get /api/hris/v1/timesheet-entry/{id}
Returns a Timesheet object with the given id.
# Get Timesheet List
Source: https://docs.bindbee.dev/hris/timesheet-entries/get-timesheet-entries-list
get /api/hris/v1/timesheet-entry
Returns a list of Timesheet entry objects.
# Get Lms Categories
Source: https://docs.bindbee.dev/lms/categories/get-categories
get /api/lms/v1/categories
Returns a list of LMS Category objects.
# Get Lms Category By Id
Source: https://docs.bindbee.dev/lms/categories/get-category-by-id
get /api/lms/v1/categories/{id}
Returns an LMS Category object with the given id.
# Get Lms Completion By Id
Source: https://docs.bindbee.dev/lms/completions/get-completion-by-id
get /api/lms/v1/completions/{id}
Returns an LMS Completion object with the given id.
# Get Lms Completions
Source: https://docs.bindbee.dev/lms/completions/get-completions
get /api/lms/v1/completions
Returns a list of LMS Completion objects.
# Get Lms Content By Id
Source: https://docs.bindbee.dev/lms/contents/get-content-by-id
get /api/lms/v1/contents/{id}
Returns an LMS Content object with the given id.
# Get Lms Contents
Source: https://docs.bindbee.dev/lms/contents/get-contents
get /api/lms/v1/contents
Returns a list of LMS Content objects.
# Get Lms Course By Id
Source: https://docs.bindbee.dev/lms/courses/get-course-by-id
get /api/lms/v1/courses/{id}
Returns an LMS Course object with the given id.
# Get Lms Courses
Source: https://docs.bindbee.dev/lms/courses/get-courses
get /api/lms/v1/courses
Returns a list of LMS Course objects.
# Get Lms Enrollment By Id
Source: https://docs.bindbee.dev/lms/enrollments/get-enrollment-by-id
get /api/lms/v1/enrollments/{id}
Returns an LMS Enrollment object with the given id.
# Get Lms Enrollments
Source: https://docs.bindbee.dev/lms/enrollments/get-enrollments
get /api/lms/v1/enrollments
Returns a list of LMS Enrollment objects.
# Get Lms Skill By Id
Source: https://docs.bindbee.dev/lms/skills/get-skill-by-id
get /api/lms/v1/skills/{id}
Returns an LMS Skill object with the given id.
# Get Lms Skills
Source: https://docs.bindbee.dev/lms/skills/get-skills
get /api/lms/v1/skills
Returns a list of LMS Skill objects.
# Get Lms User By Id
Source: https://docs.bindbee.dev/lms/users/get-user-by-id
get /api/lms/v1/users/{id}
Returns an LMS User object with the given id.
# Get Lms Users
Source: https://docs.bindbee.dev/lms/users/get-users
get /api/lms/v1/users
Returns a list of LMS User objects.
# Meta APIs for Write Operations
Source: https://docs.bindbee.dev/meta-apis-for-write-operations
Retrieve request schemas for Create Employee, Create Employee Payroll Run, Create Timesheet, and Create Time Off Request APIs.
## Overview
Meta APIs describe the request body expected by Bindbee for a specific write operation and integration. Each response follows a JSON Schema-compatible structure and includes field requirements, accepted values, formats, and nested object definitions.
Because write capabilities vary by integration, the Meta API response should be used to construct and validate the request body before submitting a write operation.
## Supported Operations
Meta APIs are currently available for the following write operations:
* Create Employee
* Create Employee Payroll Run
* Create Timesheet
* Create Time Off Request
Support may vary by integration. A write operation can be available for an integration even when its Meta API schema has not yet been implemented.
## Request Workflow
Use the following process when preparing a write request:
1. Call the Meta endpoint for the required write operation and integration.
2. Review the returned schema, including required fields, accepted values, and integration-specific parameters.
3. Construct a request body that conforms to the schema.
4. Submit the request to the corresponding write endpoint.
The schema can also be used with compatible JSON Schema tooling for request validation or form generation.
## Meta API Response Structure
A Meta API response defines the structure of the request body for the selected write operation. In addition to standard JSON Schema keywords, the response can include Bindbee-specific metadata such as `isRequired` and `enumInformation`.
The following keywords are commonly included:
| Keyword | Purpose |
| ----------------- | ---------------------------------------------------- |
| `type` | Defines the expected data type. |
| `properties` | Defines fields within an object. |
| `items` | Defines the structure of each element in an array. |
| `required` | Lists the fields required within an object. |
| `isRequired` | Indicates whether an individual field is required. |
| `description` | Provides a human-readable explanation of a field. |
| `format` | Defines an additional constraint for a string value. |
| `enum` | Lists the accepted values for a field. |
| `enumInformation` | Provides descriptions for values listed in `enum`. |
### Root Object and Field Definitions
A top-level `type` of `object` indicates that the write request body must be a JSON object. The `properties` object contains the available fields, while the `required` array lists the fields that must be included.
```json theme={null}
{
"type": "object",
"properties": {
"first_name": {
"type": "string",
"description": "The employee's first name.",
"isRequired": true
},
"last_name": {
"type": "string",
"description": "The employee's last name.",
"isRequired": true
}
},
"required": ["first_name", "last_name"]
}
```
Use `isRequired` to review the requirement for an individual field. Use the `required` array to identify all mandatory fields within an object.
### Nested Objects and Arrays
For a field with `type: "object"`, nested fields are defined under `properties`.
```json theme={null}
"home_location": {
"type": "object",
"description": "The employee's home address.",
"isRequired": false,
"properties": {
"street_1": {
"type": "string",
"description": "The first line of the street address.",
"isRequired": false
},
"city": {
"type": "string",
"description": "The city of the address.",
"isRequired": false
}
}
}
```
For a field with `type: "array"`, the schema for each array element is defined under `items`.
```json theme={null}
"earnings": {
"type": "array",
"description": "The earnings entries for the payroll run.",
"isRequired": false,
"items": {
"type": "object",
"properties": {
"earning_code": {
"type": "string",
"isRequired": true
},
"amount": {
"type": "number",
"isRequired": false
}
},
"required": ["earning_code"]
}
}
```
## Integration-Specific Fields
Meta API responses can include `integration_params` and `additional_attributes`. These fields serve different purposes.
| Field | Structure | Validation | Purpose |
| ----------------------- | ---------------- | ---------------------------------- | ------------------------------------------------------------------------------------------ |
| `integration_params` | Defined object | Validated and potentially required | Contains parameters required by the underlying integration for the write operation. |
| `additional_attributes` | Free-form object | Not defined by the unified schema | Contains integration-specific values that are not represented in Bindbee's unified fields. |
### `integration_params`
`integration_params` contains fields required by the underlying integration. Its properties are explicitly defined in the Meta API response and can be required.
```json theme={null}
"integration_params": {
"type": "object",
"description": "Parameters required by the integration for the write operation.",
"isRequired": true,
"properties": {
"pay_statement_type_id": {
"type": "string",
"isRequired": true
}
},
"required": ["pay_statement_type_id"]
}
```
### `additional_attributes`
`additional_attributes` is a free-form object for fields that are supported by the underlying integration but are not represented in Bindbee's unified model.
```json theme={null}
"additional_attributes": {
"type": "object",
"description": "Additional integration-specific attributes for the write operation.",
"isRequired": false
}
```
Values included in `additional_attributes` are forwarded to the underlying integration as part of the write request.
## Accepted Values and Validation
### `enum` and `enumInformation`
The `enum` keyword lists the values accepted by a field. When available, `enumInformation` provides a description for each accepted value.
```json theme={null}
"pay_statement_type_id": {
"type": "string",
"isRequired": true,
"enum": ["51743768", "51743769", "51743758"],
"enumInformation": [
{
"value": "51743768",
"description": "Third-Party Sick"
},
{
"value": "51743769",
"description": "Bonus"
},
{
"value": "51743758",
"description": "Regular"
}
]
}
```
The request body must use one of the values listed in `enum`. The corresponding entry in `enumInformation` can be used to determine the appropriate value.
### `description` and `format`
The `description` keyword explains the purpose of a field. The `format` keyword defines an additional constraint for a string value, such as an email address or UUID.
```json theme={null}
"work_email": {
"type": "string",
"description": "The employee's work email address.",
"format": "email",
"isRequired": false
}
```
## Constructing the Write Request
After reviewing the schema, construct a request body that includes all required fields and conforms to the defined types, formats, and accepted values.
For example, if `first_name` and `last_name` are required, the following request body is valid:
```json theme={null}
{
"first_name": "Jane",
"last_name": "Doe",
"work_email": "jane@acme.com",
"additional_attributes": {
"employee_number": "E-1042"
}
}
```
In this example:
* `first_name` and `last_name` satisfy the required field definitions.
* `work_email` conforms to the `email` format.
* `employee_number` is included as an integration-specific attribute.
## Common Errors
### Meta API Not Implemented for an Integration
A Meta API schema may not yet be available for every supported write operation and integration combination. In this case, the Meta endpoint returns the following HTTP status:
```http theme={null}
501 Not Implemented
```
Example response:
```json theme={null}
{
"detail": "Meta API is not implemented for Time Off in bamboohr. You can request this feature by contacting support@bindbee.dev."
}
```
This error indicates that the Meta API schema is not yet available for the selected integration and write operation. To request Meta API support for an additional integration or operation, contact `support@bindbee.dev`.
# Webhooks
Source: https://docs.bindbee.dev/webhooks/overview
With Webhooks, you can receive real-time updates on connector sync statuses, as well as notifications whenever HRIS data is created or modified. This ensures you stay up-to-date with the latest changes and maintain accurate, synchronized information across your systems, enhancing your workflow efficiency and data reliability.
## Create Webhooks
To create webhooks, follow the instructions below.
**Step 1:** Navigate to the “Webhooks” section from the sidebar under the “Configure” menu.