Skip to main content
Submitting a leave request writes a real record into the customer’s HRIS. What happens next is the platform’s decision rather than yours: which leave types it accepts, whether a manager has to approve it, and whether the employee has the balance for it.
Before you start
  • You’ve confirmed the integration supports this write - see Check write support.
  • You have the Bindbee id of the employee the request is for.

​
Steps

1

Fetch the schema

Pay attention to the leave-type enum and to any required integration_params. Both vary by platform - see Fetch a schema.Result: The exact contract for this integration.
2

Resolve the employee

Use the Bindbee employee id, not the employee number or the source system’s identifier. If you’re starting from an upstream identifier, resolve it first with remote_id - see Filtering.Result: A valid employee reference.
3

Send the request with an idempotency key

Use field names and enum values from the schema rather than the example above.
Always send X-Idempotency-Key. A retried request without one creates a duplicate leave request that someone has to find and cancel by hand - see Idempotency.
Result: The request is created in the source system.
4

Confirm it landed

Read it back rather than trusting the response alone - see Get Time Off.The record won’t appear in Bindbee’s synced data until the next sync. To confirm sooner, force a resync.A new request lands as REQUESTED, not approved. The source system runs its own workflow, and status moves to APPROVED, DECLINED or CANCELLED there rather than through Bindbee.Result: Verified in the customer’s system.

​
Frequently Asked Questions

Leave types are platform-specific, and a customer can define their own categories. Use a value from the schema’s enum, and read enumInformation for what each means rather than matching on the name.If the customer’s own category isn’t in the enum, it may need supplying through integration_params or additional_attributes.
Send ISO 8601 with an explicit timezone. Where a platform works in whole days, a timestamp with a time component can shift the request by a day across timezone boundaries - check whether the schema expects a date or a datetime.
Expected until the next sync. Reads serve synced data, so a record created seconds ago won’t be there yet.
An idempotency key prevents this. To clean up, cancel the duplicates in the source system - Bindbee doesn’t own the record once created.
Balances belong to the source system. Bindbee submits the request and the platform enforces the balance, so an over-balance request is rejected upstream rather than by Bindbee.
Confirm you’re sending the Bindbee id, and that the employee belongs to this connector. IDs are per connector, so an ID from another customer’s connector won’t resolve.