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 initially; 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. See Going live when you're ready to let others connect.
Credentials¶
After creating an app, you'll see two things on its settings page:
| 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 like a password. | Authorization Code flow without PKCE, and any other server-to-server token call. |
Manage client secrets¶
Secrets are managed in the Secrets section on the app's settings page.
- Create a secret. Enter a label and click Create new secret. The secret value is shown only once. Copy it immediately.
- Multiple secrets per app. Useful for rotation and for handing out 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. Behavior depends on whether you set any:
| Configuration | Allowed redirect URIs |
|---|---|
| No URIs set | http://localhost and http://127.0.0.1 on any port. Lets local development work without configuration. |
| One or more URIs set | Only the URIs you list. Localhost must be added explicitly if you still want it alongside production URIs. |
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¶
To have SweatStack push events to your app when user data changes (activities, tests, etc.), configure webhook endpoints as a comma-separated list on the app's settings page. See Webhooks for the payload format, signing, and retry behavior.
Delete an app¶
Deleting an app is permanent. The Application ID and all client secrets are gone, and any user who authorized your app loses access. Make sure nothing in production depends on the app before deleting it.