Skip to main content
POST
Record gate attendance (limited pilot)
Deployed for a limited, explicitly approved pilot. Existing integrations do not receive write:sign_on_events automatically. The pairing contract below requires agreement with the provider before rollout; deployment does not establish controller integration or general availability.

One physical event per request

Requires write:sign_on_events, a connected integrator and a worker-project site-access relationship. Reports observed attendance; it never grants or restores access. A revoked relationship still accepts historical attendance.
For sign-off, send a different stable event ID and explicitly reference the source sign-on ID for that visit:
Times must be UTC with millisecond precision or less and cannot be in the future. Event/device IDs are at most 200 characters. Extra fields are rejected.

Retries, conflicts and late delivery

  • Event identity is scoped to integrator, builder and project, across credential rotation.
  • Replaying the same ID and payload returns 200 with duplicate: true.
  • Reusing an ID with different data returns 409 and changes nothing.
  • A new applied event returns 201. Sign-offs close only the explicitly referenced visit.
  • A sign-off received first returns 202, PENDING_SIGN_ON and a null attendance ID. It is stored durably and applied atomically when its sign-on arrives. Replay the sign-off to retrieve its current status.
  • A reference to another worker, a sign-off before sign-on, or a second distinct sign-off for the same visit returns 409.
  • An already manually closed or archived attendance record returns 409; provider retries do not overwrite administrator corrections.
  • Retry network errors or server failures with the original event ID and payload. Treat payload/pairing conflicts as reconciliation work, not a reason to generate a fresh ID.
Events are audited and projected into integration-generated BuildPass attendance records using the project’s timezone for day grouping. This does not run the interactive worker sign-on questionnaire, approve safety tasks, or establish controller authorization. Worker-app state, evacuation workflows, notifications and reporting acceptance must be verified before enabling a provider pilot. Rejected attempts and visitors are not supported by this endpoint.

Authorizations

Authorization
string
header
required

The access token received from the authorization server in the OAuth 2.0 flow.

Headers

X-BuildPass-Api-Version
enum<string>
default:v1
required

What API version to use.

Available options:
v1
Example:

"v1"

X-BuildPass-Region-Id
enum<string>
default:au1

Builder database region; defaults to au1.

Available options:
au1,
us1

Path Parameters

builderId
string
required

The ID of the builder

Example:

"buil_clgbsb90b001qjy0f0eo1hspp"

projectId
string
required

The ID of the project

Example:

"proj_clgbsb90b001qjy0f0eo1hspp"

Body

application/json
sourceEventId
string
required
Required string length: 1 - 200
workerId
string
required
Pattern: ^wkr_[a-zA-Z0-9]+$
type
enum<string>
required
Available options:
SIGN_ON
occurredAt
string<date-time>
required

UTC occurrence time, millisecond precision or less; cannot be in the future.

deviceId
string
Required string length: 1 - 200

Response

Identical event replay; current processing status returned.