Going live¶

Building on SweatStack Pages?

Pages apps follow a separate, lighter publish path. See Pages. The rest of this page is about apps you host yourself.

Going live means letting other people, not only you, connect to your app. There's no review queue and no submit button: filling in four fields on the app makes it public the moment you save.

Seeing "… is still private"?¶

That page means the account you're signed in as did not create the app. It names the account, so check that line first. Three usual causes:

You're the developer, signed in as your test account. Expected: private apps are creator-only. Fill in the fields the page lists as missing and try again. Switch account on the page signs you out and brings you back to the same authorization request.
A teammate or tester opened your link. Same fix. There is no per-user allowlist for private apps. Going public is the only way to let a second account in. For a team that shares an app during development, see Use separate dev and prod apps.
You went live, but a field didn't save. The page lists what's missing. Check the Public profile section of your app's edit form.

1. Fill in the four fields¶

Open your app in Settings → API, click Edit and fill in the Public profile section. All four fields are required:

Field	What it's used for
Description	Shown on the authorization page when users connect.
URL	Where users can learn more about your app.
Image URL	Your app's logo on the authorization page.
Privacy Statement URL	Your privacy policy explaining how you handle user data.

The section shows a live status as you type, and the app's page shows the saved one:

Public when all four fields are filled in.
Private, with the exact list of fields still missing.

The moment all four are saved, your app is public. There's no waiting period.

On SweatStack Pages?

Deployed Pages apps qualify for lighter requirements: SweatStack fills in three of the four fields for you. See Pages › Publish a Page.

Optional: a brand color¶

Below the image URL you can pick a brand color. It paints the side panel on every page SweatStack shows on your behalf: sign-in, consent, the Portal. Your logo and name sit on that color next to the SweatStack mark. The text, the mark and the panel's shadow adapt to the color, so any color stays legible. Leave it unset for SweatStack blue.

Use Preview the sign-in page next to the field to see the real page in your color before you save. The preview shows your logo as it is on the color you chose, so that is the place to check that it reads well.

2. Verify with a second account¶

Confirming that login works for someone other than you takes one extra step. Do this every time you go live for the first time:

Open your authorization URL in a private/incognito window.
Sign in as a different SweatStack account, not your own.
Complete the flow. You should reach the consent screen and land back in your app.

If you see "Your app is still private" instead, see above: the page names the account you're signed in as and lists every field that didn't save.

How to get a second account

Most developers have only one SweatStack account. Two ways to get a second:

Sign up with an email alias. [email protected] works on most email providers, and the messages arrive in your existing inbox.
Connect that account to Intervals.icu. SweatStack pulls activities from Intervals.icu. Upload a few rides or runs there, and your test user has realistic data to authorize against.

3. Public means reachable, not advertised¶

Going live makes your app reachable: anyone with your authorization link can connect. SweatStack does not announce it anywhere, so you decide who gets the link and when. Ship quietly to a known group of users first if you like.

4. Request only the scopes you need¶

Scope choice is a going-live decision, not only an API detail.

Users see them. Scopes appear on the consent screen. "Read your activities" reads very differently from "read and write your activities."
They're sticky. If you add scopes later, existing users have to authorize again.

Request the minimum your app uses. See Authentication for the available scopes.

5. Use separate dev and prod apps¶

Recommended for any app you'll keep iterating on. One app is fine while you're exploring, but once you're building something real, keep two:

A dev app, private, with no explicit redirect URIs (so localhost works by default). Iterate freely.
A prod app, public, with only your production redirect URIs. Treat its credentials like production secrets.

This keeps the prod app's redirect list clean. It lets you change scopes or copy on the dev app without disturbing users who have already connected. And for teams, it gives each developer their own private app to build against, while everyone shares the prod credentials.

Teams

Only its creator can use a private app. If your team needs to share an app during development, you have to make it public. The pattern above, one dev app per developer plus a shared prod app, avoids that.

Review and good standing¶

Your app works the moment you create it. There's no approval queue. We review apps continuously and asynchronously in the background, so you can ship without waiting on us. If something looks off, we'll contact you so we can fix it together. We want every app on SweatStack to treat athletes' data with care, and our default is to help you get there.

API guidelines¶

Every public app on SweatStack is expected to:

Have a valid privacy policy. The URL must resolve and explain what you collect, what you do with it, and how users can have it removed.
Request only the scopes you need. Over-requesting damages trust and slows adoption.
Be transparent about data use. If you store data, say so. If you share data with third parties, say so. Put this in your privacy policy.

Rate limits and fair use¶

There are no published hard limits yet. In practice we don't throttle you unless your usage starts to affect other applications. If your request patterns can be made more efficient, we contact you directly before we take any action.

If you're planning a high-volume integration and want to check your approach, email us and we'll help you design it.

Questions about any of this? Email us.