Connector Overview

A connector is a real integration with an external provider, authenticated through real OAuth where the provider supports it, behind one common ConnectorSDK interface — no per-provider special-casing in how PawOS decides whether an action is allowed.

OAuth token exchange happens on PawOS’s backend, not inside the desktop app, so client secrets are never shipped to or stored on your machine.

Product disclosure

This disclosure is part of the PawOS documentation for Connector Overview. 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.