Setup¶
Create your application and configure its credentials, redirect URIs, and webhooks. For the publishing lifecycle, see Going live or Pages.
Create an app¶
Go to Settings → API and click Create Application. Only the Name is required at this point. You can fill in everything else later.
Warning
Your new app is private from the start: only your own account can complete its OAuth flow. That's the right state for development. Anyone else who opens your authorization link, including you on a second account, sees a "Your app is still private" page (what it says and why). See Going live when you're ready to let others connect.
Credentials¶
After creating an app, its settings page opens with an OAuth 2.0 integration card. Two things on it are your credentials:
| Field | What it is | Where you use it |
|---|---|---|
| Application ID | Your OAuth2 client ID. Public. Safe to ship in client-side code. | Every authorization request. |
| Client secret | Proves the app's identity in server-side OAuth flows. Treat it like a password. | Authorization Code flow without PKCE, and any other server-to-server token call. |
Manage client secrets¶
Secrets live under Credentials in the OAuth 2.0 integration card on the app's settings page, right below the client ID.
- Create a secret. Enter a label and click Create secret. SweatStack shows the secret value only once. Copy it immediately.
- Multiple secrets per app. Useful for rotation and for per-environment credentials.
- Rotate a secret. Create a new one, deploy it, then delete the old one. Tokens issued under the deleted secret stop working.
- Revoke a secret. Delete it. Tokens issued under it stop working immediately.
Warning
Never ship a client secret to a user's device (mobile app, single-page app, or anything else that runs in a browser). Use Authorization Code + PKCE instead. PKCE does not require a secret.
Redirect URIs¶
Configure redirect URIs as a comma-separated list on the app's settings page. What SweatStack allows depends on whether you set any:
| Configuration | Allowed redirect URIs |
|---|---|
| No URIs set | http://localhost and http://127.0.0.1 on any port. Local development works without configuration. |
| One or more URIs set | Only the URIs you list. If you still want localhost next to production URIs, add it explicitly. |
The same list decides where the Portal may send a user back to: a return_url must equal or sit under one of these URIs.
Accepted schemes¶
SweatStack accepts the three redirect types defined by RFC 8252 (OAuth 2.0 for Native Apps):
| Type | Example | Use |
|---|---|---|
Claimed https |
https://your-app.example.com/oauth/callback |
Web apps, and iOS Universal Links / Android App Links. |
Loopback http |
http://127.0.0.1:1410/callback, http://localhost/cb |
Desktop and CLI apps that run a short-lived local server. |
| Private-use (custom) scheme | com.example.myapp://oauth/callback, com.example.myapp:/oauth, myapp://callback |
Native mobile apps. See Build a native mobile app. |
The custom scheme does not have to be reverse-DNS: myapp://callback is accepted exactly like com.example.myapp://callback. RFC 8252 §7.1 recommends a scheme derived from a domain you control (to reduce collisions with other apps), but SweatStack does not require it.
Not accepted: public plain http:// (only loopback hosts can use http), URIs with a fragment (#…), and the web-only schemes javascript:, data:, file:, vbscript:, about:, blob:.
Matching¶
httpsand loopbackhttpmatch by sub-path: a registeredhttps://app.example.com/oauthalso allowshttps://app.example.com/oauth/callback. Loopback ports can vary.- Custom schemes match exactly (scheme, authority, and path), so register the precise URI your app uses.
Keep production apps tight: don't leave localhost on a public app's allowlist. The cleaner pattern is a separate dev app for local work. See Going live › Use separate dev and prod apps.
Webhook endpoints¶
If you want SweatStack to send events to your app when user data changes (activities, tests, uploads), configure webhook endpoints as a comma-separated list on the app's settings page. See Webhooks for the payload format, signing, and retries.
Delete an app¶
Deleting an app is permanent. The Application ID and all client secrets are gone, and every user who authorized your app loses access. Make sure nothing in production depends on the app before you delete it.