Enterprise integrations: SSO, API keys and webhooks

If The Site Book cannot check your account or sign-on provider, access pauses until the check succeeds. Retry shortly; the mobile app keeps this as a temporary error rather than signing you out. A service outage does not switch off your company’s SSO requirement.

The mobile API checks the current sign-in and refuses access when the account's SSO policy is not satisfied. In the app, enter your work email and choose Continue with SSO to open your company's identity provider. Access resumes only after the app verifies the new session. Older app versions should use the website to sign in through the identity provider.

No — the v1 API is read-only by design. Scopes cover projects, documents, workers, certifications and attendance, rate-limited at 120 requests a minute. Full reference at thesitebook.co.uk/docs/api.

SSO set-up is done with our team — Okta, Microsoft Entra ID or any SAML 2.0 provider. Email [email protected] to arrange set-up with the team. Once active, go to Settings → Integrations → Manage SSO and select "Require SSO" to enforce it for your whole team. Switching Require SSO on refuses any session that started before the switch — everyone on your domain signs in again through your identity provider, on the web and in the mobile app. The account owner keeps break-glass access.

On the website, a session that did not come through your identity provider is sent to the "Your organisation requires single sign-on" screen throughout the app, including when someone follows a link between pages. The surrounding web actions refuse it too: opening a site file download link or resuming a checkout after sign-up lands on that same screen, and upgrade, feedback, the dashboard call-back card and the start-a-project steps show a single sign-on message instead of going ahead. The screen's "Sign out and use SSO" action opens the login page for another attempt. In the native app, enter your work email and choose Continue with SSO; the app verifies the resulting session before reopening account data. Public pages such as pricing still load. Links that carry their own access rather than a login — a contractor's portal link or a document share link — keep working on their own terms.

Documents generated and signed, certificates expiring, workers checking in, inductions acknowledged, a document version sent for named approval, a version approved by its named approver, and an approved document published to your SharePoint site — each signed with HMAC-SHA256 so your systems can verify it. Webhooks never carry the PDF itself. The three document approval and SharePoint events carry identifiers only (fetch the exact version through the public API if you need it); the other events include names such as the worker, signer or certificate holder, so treat your receiving system as holding personal data.