Settings

System Settings

Account

Profile

Dome

dh@gopaxx.de

owner

Dev-mode auth. There is one real account on this instance — no login screen, no password. Real browser login exists in this codebase and is switched on with PAXX_AUTH_MODE=google plus a login OAuth client; see docs/project-brain/AUTH.md. YELLOW applies to switching it on.

Test as role

Dev-mode only: masquerades the single owner account as a lower role to test RBAC-gated UI. Never a path to more privilege than owner already has.

13 available · 1 connected · 7 need setup

Integrations

Open the Integration HubPer-provider setup checklists, administrator configuration, encrypted credential storage and live connection tests.11 action required0 degraded1 connected0 disconnected

Carrier network

carriers · shipments

MOCKSetup required

Setup required

Mock-only. `carriers` is an aggregation layer, not one provider: a real implementation is one adapter per carrier (DHL, DPD, GLS, Dachser) behind a single connector, selected by PAXX_CARRIER_ADAPTERS with one credential each. Cost realistically arrives from invoice feeds rather than tracking APIs, so the two capabilities above are likely to land separately.

health: healthy

Google Workspace (primary)

inbox-summary · important-emails · calendar · oauth-multi-account

MOCKSetup required

Setup required

In console.cloud.google.com create (or pick) a project, then enable both the Gmail API and the Google Calendar API under APIs & Services → Library.

callback URL to register: https://crm.gopaxx.de/api/integrations/google/callback

Provider setup Setup steps in Google Workspace

health: healthy

Google Workspace (second)

inbox-summary · important-emails · calendar · oauth-multi-account

MOCKSetup required

Setup required

In console.cloud.google.com create (or pick) a project, then enable both the Gmail API and the Google Calendar API under APIs & Services → Library.

callback URL to register: https://crm.gopaxx.de/api/integrations/google/callback

Provider setup Setup steps in Google Workspace

health: healthy

PAXX P1

customers · shipments · returns · inventory · warehouse · goods-flow · tickets · sla

MOCKSetup required

Setup required

Mock-only, and blocked a step earlier than the others: P1 publishes no API surface for shipments, warehouse topology or tickets today. BUSINESS_OPERATIONS.md §6 is written as the specification for that work. Nothing an administrator can paste shortens this.

health: healthy

Shopify

orders

MOCKSetup required

Setup required

Mock-only: `business/mock/shopify.ts` serves fixtures. Beyond writing the client, this provider needs a credential *per storefront* — one tenant per shop — so it becomes a multi-credential provider like Google's two account slots rather than a single token field. That design decision is why no operator form is offered yet.

Provider setup

health: healthy

Spotify

now-playing · transport · volume · devices · queue

MOCKSetup required

Setup required

developer.spotify.com/dashboard → Create app. Add exactly the redirect URI shown here under Redirect URIs — Spotify matches it exactly, and a mismatch returns only “INVALID_CLIENT: Invalid redirect URI” with no hint about which value was sent.

callback URL to register: https://crm.gopaxx.de/api/integrations/spotify/callback

Provider setup

health: healthy

Xentral

customers · orders · inventory · goods-flow · sla · commercial

MOCKSetup required

Setup required

This provider is mock-only: `packages/connectors/src/business/mock/xentral.ts` serves deterministic fixtures and there is no code that talks to Xentral. No value an administrator could paste changes that, which is why this step offers no form. The reads a real implementation must satisfy are specified in docs/project-brain/BUSINESS_OPERATIONS.md §6; it would then read XENTRAL_API_URL and XENTRAL_API_TOKEN. Until it exists, every figure sourced here carries a MOCK badge.

health: healthy

ClickUp

tasks · deadlines · workspaces

MOCKNot connected

health: healthy

GitHub

list-repositories · pull-requests · branches · import-request

MOCKNot connected

health: healthy

Obsidian

knowledge-search · recent-notes · pinned-notes · quick-capture · daily-notes

MOCKNot connected

health: healthy

Paperclip

agent-roster · company · projects

MOCKNot connected

health: healthy

Weather

current-conditions · forecast · favorites

REALConnected

Granted

readRead forecastsPublic forecast data for the places you pick.

health: healthy

PAXX

projects · approvals

MOCKBuilt in

health: healthy

Setup required

Google Workspace

Setup required

Google OAuth is not configured on this server

The integration is fully implemented — connecting an account needs credentials that only an administrator can create, and a server restart to pick them up. Each step below is one-time. Secrets belong in .env.local, which is gitignored; never commit them.

1
A Google Cloud project with the Gmail and Calendar APIs enabled
In console.cloud.google.com, create (or pick) a project, then enable both the Gmail API and the Google Calendar API under APIs & Services → Library.
2
OAuth consent screen configured
Google Auth Platform → Audience and → Data access (formerly "APIs & Services → OAuth consent screen"). "Internal" is enough for a Workspace domain. An External app must stay in Testing with each Google account added under Test users — note that Testing authorizations expire 7 days after consent, taking the refresh token with them, so Internal is strongly preferred for a daily-use tool. Add the six read-only scopes listed below. gmail.metadata is a RESTRICTED scope (not merely sensitive): an External app in Production would need Google verification plus a recurring third-party CASA security assessment. Testing mode avoids both.
3
An OAuth 2.0 Client ID of type "Web application"
Google Auth Platform → Clients → Create client (formerly "APIs & Services → Credentials"). Add exactly this Authorized redirect URI — Google matches it byte-for-byte, including scheme, case and trailing slash: https://crm.gopaxx.de/api/integrations/google/callback
4
Client ID available to the serverGOOGLE_OAUTH_CLIENT_ID
Set GOOGLE_OAUTH_CLIENT_ID in the server environment (.env.local — never committed).
5
Client secret available to the serverGOOGLE_OAUTH_CLIENT_SECRET
Set GOOGLE_OAUTH_CLIENT_SECRET in the server environment. It is read server-side only and is never sent to the browser.
✓
Token encryption keyPAXX_TOKEN_ENCRYPTION_KEY
Set PAXX_TOKEN_ENCRYPTION_KEY to a 32-byte key (openssl rand -base64 32). Refresh tokens are encrypted with AES-256-GCM before they reach the database; without this key PAXX refuses to store them rather than storing them in plaintext.
✓
Public base URL (only if PAXX is not on http://localhost:3000)PAXX_PUBLIC_URL
Set PAXX_PUBLIC_URL (e.g. https://command.gopaxx.de) so the redirect URI PAXX generates matches the one registered with Google. Alternatively set GOOGLE_OAUTH_REDIRECT_URI directly.

Authorized redirect URI — must match exactly

https://crm.gopaxx.de/api/integrations/google/callback

Still missing: GOOGLE_OAUTH_CLIENT_ID, GOOGLE_OAUTH_CLIENT_SECRET

Permissions PAXX will request — all read-only

Sign-in identityread
Identifies which Google account granted access, so the two account slots can be told apart.
Email addressread
Labels the connected account in Settings and tags every mail/calendar item with its source account.
Name and profile pictureread
Shows a recognisable account identity instead of a bare email address.
Gmail headers and labels — no message bodiesread
Reads sender, subject, timestamp, labels and thread structure. Google will not return message bodies or attachments under this scope.
List of your calendarsread
Lets PAXX show which calendar an event came from when several are connected.
Calendar eventsread
Reads today's schedule, upcoming events, attendees and meeting links.

Until OAuth is configured, Gmail and Calendar panels across the Command Center are served by the mock connectors and carry a MOCK provenance badge. No Google account is contacted and no credential exists.

Primary Google account

No account connected to this slot. Two Google accounts are supported — connect them one at a time; Google's account chooser is shown each time, so the second connection can use a different account.

Picking an account that already occupies the other slot moves it here and leaves that slot empty — one Google identity can only be connected once.

Connect — unavailable until setup is complete

Second Google account

No account connected to this slot. Two Google accounts are supported — connect them one at a time; Google's account chooser is shown each time, so the second connection can use a different account.

Picking an account that already occupies the other slot moves it here and leaves that slot empty — one Google identity can only be connected once.

Connect — unavailable until setup is complete

Open Mail Open Calendar

Security boundary

What PAXX can and cannot do with these accounts

GREEN Read mail metadata and calendar events. Active. Headers, labels, thread structure, events, attendees. No message bodies — the gmail.metadata scope does not return them.

YELLOW Connect, reconnect, disconnect, toggle a capability. Requires the integrations:configure capability (admin or owner) and is recorded in the audit log with the scopes granted. Google's own consent screen is a mandatory human approval step inside the flow, which is why this is YELLOW rather than RED despite storing a credential.

RED Send email, create a draft in Gmail, or modify a calendar. Not implemented and not reachable: no send/compose/modify scope is requested (a unit test fails if one is added to the scope table), and the send helper throws unconditionally. Enabling it would be a deliberate, reviewable change requiring per-message human approval.

Refresh tokens are encrypted with AES-256-GCM before they reach the database and live in a separate table from the account record, so listing accounts never reads ciphertext. No token is ever sent to the browser. Disconnecting revokes the grant at Google first, then deletes the local credential.

Policy

Security classes

GREEN read, analyze, code, test, build, local commits — autonomous·YELLOW dependency/migration/infra changes — confirm first·RED deploys, destructive ops, external comms, secrets — explicit human approval

RBAC matrix

Role capabilities

Capability	owner	admin	member	viewer
Approve YELLOW actions	✓	✓	✓	—
Approve RED actions	✓	✓	—	—
Configure integrations	✓	✓	—	—
Manage settings	✓	✓	—	—
View audit log	✓	✓	✓	—
Manage users	✓	—	—	—

0 shown

Recent audit events

No audited actions yet.

Command Core

System Settings

Profile

Integrations

Google Workspace

What PAXX can and cannot do with these accounts

Command Center

Command history

Security classes

Role capabilities

Recent audit events

Knowledge access

Grants

Weather locations

Command resolution

Engineering agents

Persistence

System health