Capture API and Webhooks

Create a token

Owners and admins can open Settings → Capture → API & webhooks and create a personal access token. Give each integration its own name, choose the smallest scopes it needs, and set an expiry where practical. The jsc_ token is shown once; JobsiteOn stores only its digest and last four characters. Revoking one token stops it immediately without affecting the other integrations.

Tokens are bound to Sandbox or Live. Start in Sandbox and never put a token in a URL, browser bundle, or committed file.

Use the API

The canonical machine-readable resources are:

• OpenAPI 3.1
• Postman collection
• AI-agent index

Send Authorization: Bearer <token>. Lists use opaque cursors and return { data, pagination }; failures return { error: { code, message } }. Write operations require an Idempotency-Key so a retry cannot create duplicate work.

Verify webhooks

Compute HMAC-SHA256 over ${timestamp}.${rawBody} with the endpoint secret. The X-JobsiteOn-Signature header contains one or more comma-separated v1=<hex digest> values; accept the request when any value matches in constant time. Reject stale X-JobsiteOn-Timestamp values before processing. After a secret rotation, the current signature is first and the previous-secret signature remains in the header for 24 hours, so receivers can move to the new secret without an outage. Deliveries retry with bounded backoff and move to the dead-letter view after exhaustion.

The Webhooks section lists the supported event catalog and lets an owner or admin create, edit, disable, re-enable, rotate, or delete an endpoint. Open Deliveries to filter recent attempts, inspect response status and failure details, and explicitly redeliver a dead-letter event after fixing the receiver. Endpoint secrets are also shown only once.

Choose event names

New integrations should subscribe to the canonical Capture catalog:

• Projects: capture.project.created, capture.project.updated, capture.project.archived
• Assets: capture.asset.created, capture.asset.ready, capture.asset.failed, capture.asset.tagged
• Work: capture.comment.created, capture.checklist.completed, capture.checklist.item_completed, capture.task.completed, capture.workorder.status_changed, capture.report.ready
• Customer activity: capture.proposal.sent, capture.proposal.viewed, capture.proposal.signed, capture.proposal.declined, capture.share.viewed, capture.review.completed

Older subscriptions may continue using capture.asset.uploaded and capture.workorder.created, capture.workorder.updated, or capture.workorder.completed. Asset upload means bytes first became available; it is not the same as durable asset creation. A real work-order transition sends both canonical status_changed and the applicable older update/completion event. Subscribe to one work-order vocabulary to avoid processing the same transition twice. A Data Saver preview does not send canonical asset readiness; that event is sent once after the immutable original finishes processing. capture.asset.failed covers both failed and malware-quarantined assets, and the payload's asset state tells you which occurred.