Google Workspace

Uses real PKCE OAuth with incremental authorization — PawOS requests only the specific scope a capability needs (Drive, Gmail compose, Calendar, Contacts) at the point it’s actually needed, not one broad upfront grant.

Product disclosure

This disclosure is part of the PawOS documentation for Google Workspace. It is written to make the product behavior understandable before a user relies on it, pays for it, connects an account, approves a plan, or authorizes a machine-affecting action.

What users see

• Connector setup, connected/disconnected state, scope prompts, provider-specific authorization pages, restore behavior, entitlement blocks, and action-level confirmation prompts.
• Users may see different capabilities per connector: ticket read, repository read, PR/MR listing, comments, deployment actions, OAuth restore, or status checks.
• A connector page should state whether the connector can read, write, comment, deploy, restore, or only authenticate.

What PawOS does

• PawOS uses connector SDK implementations and stored credentials to call external provider APIs only for supported actions.
• OAuth and token flows are scoped by connector and may request incremental authorization for additional capabilities.
• Connector entitlement gates prevent unavailable-tier users from activating or restoring blocked connectors.

Permissions and boundaries

• Connecting an account does not authorize every future action. Posting comments, deploying, rollback, promotion, or other side-effecting actions still require the relevant confirmation and policy checks.
• A provider integration can be real while a specific action for that provider remains not implemented.
• If credentials are missing, expired, out of scope, or blocked by tier, PawOS must report that condition rather than silently continuing.

Evidence and records

• Connector evidence should include provider identity, action result, target object where safe to show, and any failure returned by the provider.
• For PR/MR or deployment claims, the docs should distinguish local self-report from provider-confirmed state.

Limitations and user responsibility

• Connector APIs vary by provider and organization settings; the same request can succeed for one connected account and fail for another.
• Some connector pages document authentication and read capability while write-back remains explicitly not implemented.