Skip to content

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 just you, connect to your app. There's no review queue and no submit button: filling in four fields on the app flips it public the moment you save.

1. Fill in the four fields

Open your app in Settings → API and expand the Ready to go live? 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 Ready to go live? panel shows a live status:

  • ✅ Ready for public use when all four fields are filled in.
  • ❌ Not ready for public use 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: three of the four fields are filled in for you. See Pages › Publish a Page.

2. Verify with a second account

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

  1. Open your authorization URL in a private/incognito window.
  2. Sign in as a different SweatStack account, not your own.
  3. You should reach the consent screen and complete the flow.

If you still see "this application is private," you're either signed in as the app's creator, or one of the four fields didn't save. Check the Ready to go live? panel.

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; messages land 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. Choose what to expose: public vs. listed

These are two distinct settings. Most developers conflate them.

Setting What it means How to set it
Public Anyone with your authorization link can connect. Automatic when all four fields are filled in.
Listed Your app additionally appears in the public Apps directory, where users can discover it on their own. Tick Publish to App Directory on the app's settings. Independent of public/private.

Most production apps stay public-but-unlisted at first: ship quietly to a known group of users, then list once you're ready for broader discovery.

4. Request only the scopes you need

Scope choice is a going-live decision, not just 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 re-authorize.

Request the minimum your app actually 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 poking around, 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, lets you change scopes or copy on the dev app without disturbing users who've already connected, and (for teams) gives each developer their own private app to build against while everyone shares the prod credentials.

Teams

A private app can only be used by its creator. If your team needs to share an app during development, you'll have to make it public. The dev-per-developer + shared-prod pattern above 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 reach out so we can sort it out 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.

Questions about any of this? Get in touch.