CremindProviders
The accounts you can link through Cremind Connect today — Google (Gmail, Calendar) via loopback PKCE and Atlassian (Jira, Confluence) via 3LO — and how each flow works.
Cremind Connect is multi-provider by design. Each provider plugs in as a module, so the routes and the relay's core stay provider-agnostic. This page covers what you can link today and how each flow behaves.
Provider summary
| Provider | Resources | Auth flow | Real-time events |
|---|---|---|---|
| Gmail, Calendar | Loopback PKCE (Desktop) | Yes — Gmail (Pub/Sub) and Calendar (webhook) | |
| Atlassian | Jira, Confluence | OAuth 2.0 (3LO) | Jira: yes. Confluence: content-access today, events planned |
Google — Gmail and Calendar
Google links use the loopback PKCE flow described in The two-plane model. Your app drives the consent in your browser, exchanges the code directly with Google, and stores the tokens locally. The relay is never in the token path.
For real-time events, your app registers watches with Google using its own token:
- Gmail publishes change notifications into the organization's shared Pub/Sub topic; Google pushes them to the relay with a signed OIDC JWT that the relay fully verifies.
- Calendar sends header-only webhook notifications to the organization's domain-verified webhook URL; the relay parses the routing key from the channel id.
In both cases the relay turns the verified push into a content-free resync nudge and fans it out.
Watch renewal is your app's job
Provider watches expire (Google's within about seven days). Renewing them is handled by your app's always-on listener, not by the relay — which is part of why the relay holds no per-user lifecycle state.
Atlassian — Jira and Confluence
Atlassian links use OAuth 2.0 (3LO), a confidential flow. A single Atlassian developer app covers both the Jira and Confluence skills. Because the flow requires a client secret at the token exchange, the relay mediates that exchange and refresh, holding the secret server-side — then hands the tokens straight back to your app and stores nothing. (See the Atlassian section of the two-plane model.)
Jira
Jira is fully supported, including real-time events via dynamic webhooks. When an issue changes, the relay nudges your app, which then pulls the change with its own token (for example, via a JQL query) and hands it to the skill.
Confluence
Confluence is content-access today: your app can read and write Confluence content through the API (for example, search and pages). Real-time Confluence events are planned, not yet available — OAuth (3LO) apps have no Confluence webhook path, so event support is deferred to a later integration. Until then, Confluence-driven skills poll rather than receive push nudges.
Confluence real-time events are not available yet
You can link Confluence and access content through it now, but it does not deliver live events through Connect yet. Frame any event-driven Confluence workflow as forthcoming.
Linking flow (all providers)
Regardless of provider, the user-facing flow is the same short browser interaction:
- The skill surfaces a consent URL.
- You approve in your browser.
- Cremind's always-running backend loopback listener catches the redirect, so the link completes in the background — there's nothing to paste back.
- The skill saves your tokens locally.
Atlassian needs a running backend
Atlassian's 3LO flow uses one fixed, pre-registered loopback callback, so linking an Atlassian account requires Cremind's backend to be running. The Google skills can fall back to an ephemeral-port loopback, but the experience is the same: approve in the browser, and the link finishes on its own.
More providers
Because providers are pluggable, the set can grow over time without changing the relay's core. For the current list, deployment details, and the design of the provider model, see the Connect site and repository.
The two-plane model
How Cremind Connect separates the authorization plane (your tokens, kept local) from the event plane (content-free nudges relayed in real time) so the relay never needs to hold your data.
Privacy and trust
What Cremind Connect can momentarily observe, what it provably never keeps, and why being stateless at rest and fully open source makes it auditable.