Setup¶

Create your application and configure its credentials, redirect URIs, the data it uses and its webhooks. For the publishing lifecycle, see Going live or Pages.

Protect your developer account¶

Your developer account controls your apps, and through them the data of every athlete who connected. So SweatStack asks for a passkey before sensitive actions on your apps, such as creating an app or changing its credentials, redirect URIs or webhooks.

Signing in does not change. Your apps keep running whether or not you have a passkey.

Add a passkey¶

Go to Settings → Passkeys.
Click Add a passkey and follow your browser's prompt.
Save the recovery codes that SweatStack shows. SweatStack shows them once, and each code works once.
Add a second passkey on another device, so that losing one device does not lock you out.

Any passkey works: your browser's or operating system's, a password manager's, a security key, or your phone over the QR code your browser offers.

Confirm an action¶

When an action needs your passkey, SweatStack asks for it on the same page and then completes the action.

With the CLI, your browser asks for your passkey when you run sweatstack login. If a command says that it needs your passkey, run sweatstack login and then the command again.

Recover your account¶

If you cannot use a passkey, use a recovery code instead. If you have no passkey and no recovery code left, email info@sweatstack.no from your account's email address. SweatStack never removes a passkey on an email alone: we first check that the request is yours, which can take up to three days.

SweatStack emails you when a passkey is added or removed and when a recovery code is used.

Create an app¶

Go to Settings → API and click New App. The form has three fields:

Name (required): shown to users on the sign-in and consent pages.
Redirect URIs (optional): comma-separated. Leave it empty to use any localhost address while you build. See Redirect URIs.
Data your app uses (optional): the categories your app reads or writes. See Choose the data your app uses.

Click Create application. The app's Overview tab opens.

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.

Find your way around your app¶

Your app's page at https://app.sweatstack.no/applications/{id} has ten tabs. Each tab has its own URL. Each tab edits its own settings in place and saves only those settings. If you leave a tab with changes you have not saved, your browser asks first.

Tab	What it holds
Overview	The Next steps checklist, and a Quick start with your app's website (or its Page), your client ID and a pre-filled authorization URL.
OAuth	Client ID, client secrets, the authorization URL, token URL and request header, the scopes the authorization URL asks for, and your redirect URIs.
Consent screen	Everything users see when they connect: name, logo, description, website, privacy policy, brand color, and the data your app uses with a purpose for each category. This is where your app goes live. Its tab shows how many fields are still missing, and the tab lists them, each linking to its field.
Webhooks	Webhook endpoints and the signing secret.
Data sources	The providers your users can connect, and your own keys for them.
Pages	Your app's SweatStack Pages site.
Monitoring	Usage: the people who used your app, by month or day.
Billing	Your app's plan. Paid plans are coming soon; see pricing.
Security	Your app's security log.
Settings	Deleting the app.

The header on every tab shows whether your app is Private or Public, and exactly what is missing before anyone else can connect.

The Next steps checklist on the Overview tab has four steps:

Create the app.
Authorize with your own account. Click Open next to the authorization URL in Quick start and complete the flow. The step ticks itself when your app receives its first token.
Fill in the consent screen. The step lists what is still missing and links to each field.
Live. Anyone with a SweatStack account can connect.

For an app registered before 13 October 2026, the Overview tab also shows how to move off data:read and data:write before 13 April 2027. See Before October 2026.

Credentials¶

Your credentials are on the OAuth tab, in the OAuth 2.0 integration card. The client ID is also under Quick start on the Overview tab.

Field	What it is	Where you use it
Client ID	Your OAuth2 client ID, the same value as the Application 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 Client secrets on the OAuth tab, 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. Before it deletes a secret, the page asks you to confirm and shows when the secret was last used.

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¶

Edit redirect URIs on the OAuth tab, in the Redirect URIs card. Each URI has its own field. Click Add a redirect URI to add a field, Remove to remove one, and Save redirect URIs to save the list. The authorization URL on the OAuth tab and the Overview tab uses the first URI in the list.

If your app is public and people connected to it in the last 30 days, removing a saved URI asks you to confirm first and shows how many people connected. If your app still sends that URI, their next sign-in fails.

What SweatStack allows depends on whether you set any URIs:

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¶

https and loopback http match by sub-path: a registered https://app.example.com/oauth also allows https://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.

Test a redirect URI¶

Under Test a redirect URI on the OAuth tab, paste the exact redirect_uri your app sends and click Test. The page tells you whether sign-in would accept it, and why: which saved URI it matches, or the reason it is refused. It runs the same check as the authorization endpoint, against the saved redirect URIs, so save your changes before you test.

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.

Choose the data your app uses¶

Under Data your app uses on the Consent screen tab, tick what your app uses in each category: read or write for Activities, Wellness, Reproductive health, Workouts and Sharing, and use for Email. The create form has the same checkboxes. They don't list sign-in, the user's name and background access: the pre-filled authorization URL always adds openid, profile and offline_access. What you tick does two things:

It pre-fills the scopes in the authorization URL on the OAuth and Overview tabs. Your app's access comes from the scopes your code sends, not from these checkboxes. See Scopes.
It decides which account-status issues SweatStack reports to an app that still sends data:read. See Choose the data your app uses.

Each ticked category has a Why does your app need this? field: the purpose the user reads on the consent screen, 20 to 160 characters. Purposes are optional while your app is private. Before anyone else can connect to a category, it needs a purpose. See What makes a good purpose.

Webhook endpoints¶

If you want SweatStack to send events to your app when user data changes (activities, tests, uploads), enter webhook endpoints as a comma-separated list on the Webhooks tab and click Save webhooks. On the same tab, click Generate secret (or Roll secret) to create the secret that signs every delivery. A new secret takes effect when you save. See Webhooks for the payload format, signing, and retries.

Read the security log¶

The Security tab lists every change to who can get your app's tokens or where its data goes: client secrets created and revoked, redirect URIs, webhook endpoints and their signing secret, the data your app uses, your own provider keys, going live, and a change of owner or a suspension by SweatStack. Each entry says who made the change and when. Changes to the consent screen's copy are not listed, and nothing in the log can be edited or deleted. Secrets never appear in it; a client secret shows by its label and last four characters.

Delete an app¶

Click Delete application on the Settings tab. 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. A suspended app cannot be deleted until the suspension is lifted.