Skip to main content
Before you start
  • You’ve confirmed the integration supports this write - see Check write support.
  • You have the Bindbee employee id.

​
Steps

1

Fetch the schema

Check how the platform expects hours to be expressed - start and end timestamps, or a duration - since this varies and determines how you model entries on your side.Result: The contract for this integration.
2

Build the entry

Send ISO 8601 with explicit timezones. Time and attendance is where timezone handling bites hardest - an entry sent in the wrong offset lands on the wrong day and, near a period boundary, in the wrong pay period.Result: A body matching the schema.
3

Send with an idempotency key

Derive the key from the employee and the shift - timesheet-{employee_id}-{start_time} - so a retry of the same shift can’t create a second entry. Duplicated hours flow into pay.Result: The entry is created upstream.
4

Verify

Read it back - see Get Timesheet Entries - and confirm it appears against the intended date.Result: Confirmed in the customer’s system.

​
Entries versus punches

Some platforms model time as discrete punch events - clock in, clock out - rather than as an interval with a start and end. Where that’s the case, one logical shift may not correspond to one entry, and a break can split a shift into several. Read the schema rather than assuming an interval model, and check how the customer’s own reporting counts a shift before writing bulk entries.

​
Frequently Asked Questions

Timezone. Send an explicit offset and confirm which timezone the platform interprets entries in - the employee’s, the location’s, or the account’s. They aren’t always the same.
Most systems reject overlapping entries for one employee. Check for an existing entry covering that window before writing, particularly when backfilling.
Time periods close for approval and payroll processing. A write against a closed period is rejected, and the correction is usually an adjustment in the current period rather than an edit to the closed one.
Rounding rules, break deduction, and overtime calculation are applied by the source system after the write. The entry can be correct while the derived total differs - compare raw entries, not computed totals.
Write sequentially with per-entry idempotency keys rather than in parallel, and watch the rate limit of 200 requests per minute per connector token. Partial failure mid-backfill is easier to resume with deterministic keys.