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
| Boundary | Question | Expected control |
|---|---|---|
| Identity | Who is making the request? | Verify the authenticated person or service at the server boundary. |
| Workspace | Which company and location are active? | Resolve an explicit authorised workspace; never trust a browser identifier as authority. |
| Capability | May this actor perform this operation? | Check the exact read, correction, validation, approval, or release capability. |
| Environment | Where may the operation run? | Keep private synthetic evaluation separate from any future production access. |
Workspace switching
- List only workspaces the authenticated identity may use.
- Ask the person to select one explicit workspace.
- Create or rotate an opaque, revocable scope session on the server.
- Clear prior workspace data before loading the new context.
- 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
| Condition | Response |
|---|---|
| Unauthenticated | Stop before resolving operational data and direct the user through the approved sign-in path. |
| Scope unavailable or stale | Clear scoped state and require explicit selection again. |
| Capability denied | Do not retry with changed identifiers or reveal whether an inaccessible record exists. |
| Authority service unavailable | Fail 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.