Private product previewReview the controlled design-partner evaluation path.Explore
DevelopersAuthentication & scope

Developer docs · Private preview

Authentication and workspace scope

ZeroClickShip is designed around explicit workspace scope. Access is provisioned privately; this page describes the control model without publishing credentials or a production API host.

Availability. The current app and API hosts are protected by Cloudflare Access. Only liveness and readiness operations are included in the publication-safe schema; that schema does not promise an unauthenticated network endpoint. No token or client credential is issued by this site.

Four checks, one request

BoundaryQuestionExpected control
IdentityWho is making the request?Verify the authenticated person or service at the server boundary.
WorkspaceWhich company and location are active?Resolve an explicit authorised workspace; never trust a browser identifier as authority.
CapabilityMay this actor perform this operation?Check the exact read, correction, validation, approval, or release capability.
EnvironmentWhere may the operation run?Keep private synthetic evaluation separate from any future production access.

Workspace switching

  1. List only workspaces the authenticated identity may use.
  2. Ask the person to select one explicit workspace.
  3. Create or rotate an opaque, revocable scope session on the server.
  4. Clear prior workspace data before loading the new context.
  5. Revalidate current authority on every protected operation.

A valid identity session is not permission to read every workspace. A stale or revoked scope must fail closed, and the UI must not keep showing data from the previous selection.

Failure behaviour

ConditionResponse
UnauthenticatedStop before resolving operational data and direct the user through the approved sign-in path.
Scope unavailable or staleClear scoped state and require explicit selection again.
Capability deniedDo not retry with changed identifiers or reveal whether an inaccessible record exists.
Authority service unavailableFail closed; do not fall back to client-provided scope.

Implementation responsibilities

  • Keep credentials in an approved server-side secret store and out of code, logs, browser storage, and support messages.
  • Use secure, short-lived sessions with explicit expiry and revocation.
  • Log safe request references and outcomes without unnecessary customer or provider payloads.
  • Re-check authority before consequential local actions and after workspace changes.

For retries and unknown outcomes, see Reliability. For the published schema, see API reference.