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: you go live on your app's Consent screen tab, and the save that completes it makes your app public at once. SweatStack can ask for your passkey when you save it; see Protect your developer account.

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. Fill it in on your app's Consent screen tab, whose header shows the same list.

You never see the "still private" or "isn't released yet" page for your own app. When you go through your own authorization flow and SweatStack would refuse anyone else that request, your consent screen starts with an error instead. It says what everyone else sees ("Your app is still private" or "Your app isn't released yet") and exactly what to fill in. Fix it now opens the field on your app's Consent screen tab.

SweatStack refuses everyone else in two cases:

Your app is private: one of the four required fields is empty.
The request asks for a category that has no purpose. A request that sends data:read or data:write never needs purposes.

While either case applies, SweatStack never skips your consent screen, even if you granted the same scopes before or send prompt=none. Your own sign-in always shows you the problem.

1. Fill in the consent screen¶

Open your app in Settings → API and go to its Consent screen tab. This tab is the only place your app goes live. It holds everything users see, in the order they see it: Name, Logo URL, Description, Website, Privacy policy URL, Brand color, and Data your app uses.

Four fields are required for your app to be public:

Field	What it's used for
Description	Shown on the sign-in and consent pages when users connect.
Website	Where users can learn more about your app.
Logo URL	Your app's logo on the sign-in and consent pages.
Privacy policy URL	Your privacy policy explaining how you handle user data.

Your app is public once all four are saved. There's no waiting period.

Going live also means a purpose for each category your app uses. Under Data your app uses, every ticked category has a "Why does your app need this?" field. If a category has no purpose, SweatStack refuses anyone but you who connects asking for it: they see "Your app isn't released yet". See What makes a good purpose.

The save that takes your app live also asks you to accept the developer terms (Part B of the terms) and the Data Processing Agreement, on behalf of the organization that operates the app: one checkbox above Save, once per version of those documents. Until then it is the last item of the checklist, developer_terms in the API's go_live_missing. When the documents change after your app is live, nothing is switched off: a line at the top of your app's pages asks you to accept the new version.

A live preview of the real sign-in and consent pages sits beside the form. It changes as you type, before you save.

The Save button says what the save will do:

Save: your app stays private, or stays public.
Save and go live: this save makes your app public.
Save and make private: this save empties a required field of a public app. The page asks you to confirm and shows how many people connected in the last 30 days. Each of them is refused on their next sign-in until the field is filled in again.

The header on every tab of your app shows Private or Public, and the exact list of what is still missing before anyone else can connect.

On SweatStack Pages?

Deployed Pages apps qualify for the Pages fast track: SweatStack fills in up to three of the four fields and suggests a purpose for each category. See Pages › Publish a Page.

Optional: a brand color¶

On the Consent screen tab 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.

The preview beside the form shows the real page in your color before you save. It 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. If you see "Your app isn't released yet", a category your app requests has no purpose.

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. you+test@yourdomain.com 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¶

Each category is a line on the consent screen, with your reason one tap away. A user who sees three lines they understand connects; a user who sees eight they do not, leaves. Request the categories your app uses and nothing else: Scopes. The scopes you tick under Data your app uses on the Consent screen tab pre-fill the authorization URL on your app's OAuth and Overview tabs.

What makes a good purpose¶

Under Data your app uses on the Consent screen tab, every category you tick has a "Why does your app need this?" field. It is optional while your app is private and required once it is public: a user who is not you, connecting to an app that requests a category without a purpose, sees "Your app isn't released yet" instead of the consent screen. Its button takes them back to your redirect URI with error=access_denied and your state, as any refused authorization does. You never see that page yourself: your own consent screen tells you instead, naming the categories still missing a purpose. The preview beside the form shows your purposes as the user will read them.

One purpose per category, 20 to 160 characters, plain text, no links; your privacy policy is already on your consent screen for the detail. Write it in the user's words, completing "Your app needs this to ...":

To analyse your rides and show your training load.
To adjust your plan to how recovered you are.
To put your coach's sessions on your watch.

What does not work: For app functionality. Required. A paragraph from your privacy policy. These say nothing a user can weigh, and SweatStack may disable an app whose stated purposes do not match what it does.

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.