Concepts

Accounts and apps

One CorrConnect account can be an athlete, a developer or both. Apps belong to an account, and athletes grant access to apps.

Accounts

A CorrConnect account is an email address and a password. Athletes use it to add workouts and approve apps; developers use the same kind of account to register apps. Passwords are 12 to 128 characters and use at least three of uppercase, lowercase, numbers and symbols.

In production every account verifies its email address before it can sign in, approve an app or have its data read. An unverified athlete's tokens stop working, and CorrConnect sends no activity.created events for them.

Apps

An app is what athletes see on the consent screen and what tokens are issued to. Each one has:

Field	Notes
`client_id`	`app_` and 32 hex characters. Public: it goes in authorize links and token requests.
`name`	2 to 80 characters, shown to athletes when they approve.
`redirect_uris`	1 to 5 exact callback URLs. Authorization codes only go to one of these.
`client_type`	Always `public`.
`rate_limits`	`{"tier": "free", "per_15_minutes": 100, "per_day": 10000}` unless we raised them for you.

An account can own up to 10 apps. Registering is limited to 20 an hour per account and 60 an hour per network address. An attempt turned away because the account already has 10 apps still counts; one rejected for a malformed callback URL doesn't. Deleting an app frees its slot, and also deletes its grants, tokens and webhook subscriptions straight away.

Public clients only

Every CorrConnect app is a public client: there is no client secret to store, rotate or leak. Each authorization proves itself with a PKCE verifier instead, so a stolen code is useless without the verifier that started that one attempt. This works the same for a web backend, a mobile or desktop app, or a script.

CorrConnect sends no CORS headers, so JavaScript running in a browser on your own site can't call /oauth/token or the /v1 routes directly. A single-page app sends the athlete to the authorize link as usual, then hands the code and verifier to your backend, which does the exchange and the API calls.

Callback rules

CorrConnect compares redirect_uri character by character with the list you registered, at authorization and again at token exchange. A callback must be:

an absolute https:// URL,
without a #fragment, a user name or password, or a * wildcard,
no longer than 500 characters.

Plain http://localhost, http://127.0.0.1 and http://[::1] callbacks work only on a local development server; the hosted service refuses them. Query strings are allowed and are part of the exact match; CorrConnect adds code and state to the ones you registered.

The console session

App and webhook management uses your signed-in CorrConnect session, not an API token. The Developer workspace in the portal does this for you. To script it, sign in with POST /v1/account/login, keep the session cookie, and send these with every change:

Origin: exactly your CORRCONNECT_BASE address.
X-CSRF-Token: the csrf_token from sign-in. GET /v1/account/me returns a fresh one and retires the old one.

Sessions last 12 hours. The cookie is __Host-corrconnect_session on the hosted service. These routes only answer on the portal address; the API host returns 404 not_found for them. See the console session reference.

Two addresses

CORRCONNECT_BASE serves everything: the consent screen, the portal, the console routes and the API. The service can also run a separate API-only host that answers just the token, revoke, profile and activity routes (and /healthz and /openapi.json). If your invitation includes one, you can point server-side token and data calls at it. Session cookies never reach it.