SweatStack Pages¶

Beta

The go_live_missing field is in beta and is subject to breaking changes. If you plan to use it in production, email info@sweatstack.no before you integrate, so we can tell you about changes in advance and help you migrate.

Building a server-side OAuth app instead?

Apps you host yourself follow a different publish path with more requirements. See Going live.

SweatStack Pages hosts a static site for your app at https://{slug}.pages.sweatstack.dev. It's the right choice for single-page web apps that talk to the SweatStack API directly from the browser. If your app needs a server (to store data, hold secrets, or run background jobs), use Going live instead.

A SweatStack Pages app is the same OAuth2 application as any other. It gets a simpler publish path, the Pages fast track, because SweatStack knows the app is pure client-side.

Publish a Page¶

The publish flow for Pages apps is shorter than for self-hosted apps. Work through the steps below.

1. Deploy your Page¶

The Page must exist before you deploy to it. Create it on your app's Pages tab (open the app from Settings → API), or create the app and its Page in one command with sweatstack app create "My App" --page myapp.

Then deploy with the CLI:

sweatstack page deploy myapp ./dist

This uploads your ./dist directory to the Page. If the deploy succeeds and anything is missing before others can connect, the CLI prints the list and a link to your app's Consent screen tab. If the Page does not exist, the deploy fails with 404.

For CI/CD or other tooling, call the HTTP API directly.

2. Confirm eligibility¶

The Pages fast track applies only to real client-side apps. To qualify, your app must have:

A deployed Page.
No webhook endpoints configured.
No external redirect URIs. Only the Pages URL and localhost are allowed.

If your app needs webhooks or redirect URIs outside Pages, go live the ordinary way instead.

3. Take the Pages fast track¶

Pages apps run entirely in the user's browser. There's no server holding tokens or processing user data, so SweatStack can fill in most of the consent screen for you.

Open your app's Consent screen tab. For an eligible app, it starts with a box: Hosted on SweatStack Pages?
Tick My app runs entirely in the user's browser.
Tick User data is never sent to my servers or anyone else.
Write the Description: one or two sentences about what your app does.
Click Save and go live.

Ticking both boxes sets the Privacy policy URL to SweatStack's standard privacy policy for client-side apps and locks it. Where you have not filled them in, it also fills in:

Field	SweatStack fills in
Website	Your Pages address, `https://{slug}.pages.sweatstack.dev`.
Logo URL	The SweatStack Pages icon.
Why does your app need this?	A standard purpose for each category you tick under Data your app uses.

These stay editable: change them at any time, and the fast track never writes over them. The standard purposes say what the app uses and that the data stays in the browser. For activities: "To use your activities and training history in the app. It runs in your browser and never sends your data to its developer or anyone else."

Unticking a box removes that privacy policy: link your own.

The fast track can't request the user's email address: the Email category is unticked and can't be ticked. If your app needs the email address, go live the ordinary way and write your own purposes.

4. Verify with a second account¶

Open your Pages URL in a private/incognito window and sign in as a second account. You should reach the consent screen and complete the OAuth flow end to end.

5. Public means reachable, not advertised¶

Public means anyone with your authorization link can connect. SweatStack does not announce your app anywhere. You decide who gets the link and when.

Review and API guidelines¶

The same rules apply as for self-hosted apps: continuous asynchronous review, and the API guidelines every public app follows. See Going live › Review and good standing for the full statement.

API reference¶

Most developers should use the CLI: sweatstack page deploy handles authentication, the multipart upload, and file collection in one command. The HTTP API below exists for the cases the CLI doesn't fit: CI/CD in a different language, custom tooling, or deploying from a serverless function.

Authentication¶

The Pages endpoints authenticate as the principal user: the user who owns the application. Use your personal API key, or an access token issued to you. Not an access token that a third-party app obtained through OAuth2.

Every endpoint needs a valid token of your own account; no scope is required. Get an API key at Settings → API.

Create a page¶

POST /api/v1/pages registers a page slug for an application. The slug becomes the subdomain.

curl -X POST "https://app.sweatstack.no/api/v1/pages" \
    -H "Authorization: Bearer {your_access_token}" \
    -F "application_id={your_application_id}" \
    -F "slug=myapp"

Form fields:

application_id (required): the application the page belongs to.
slug (required): the subdomain. SweatStack lowercases it and checks it against reserved words.

The API returns the page:

{
    "slug": "myapp",
    "published": false,
    "application": {
        "id": "app_...",
        "name": "My App",
        "is_private": true,
        "go_live_missing": [
            {"field": "description", "label": "description"},
            {"field": "purpose.activities", "label": "purpose for Activities"}
        ]
    },
    "url": "https://myapp.pages.sweatstack.dev"
}

If the slug is taken, reserved or invalid, the API returns 400. A new page starts unpublished. Deploying files publishes it.

application.go_live_missing (beta) lists what is missing before anyone but you can connect to everything your app requests by default. Each item has a field and a label, a short phrase to show a person. The empty profile fields come first (description, url, image, privacy_statement), then purpose.<category> for each category under Data your app uses that has no purpose. An empty list means nothing is missing. POST /api/v1/applications returns the same field.

Get a page¶

GET /api/v1/pages/{slug} returns the page.

curl -X GET "https://app.sweatstack.no/api/v1/pages/myapp" \
    -H "Authorization: Bearer {your_access_token}"

The response has the same shape as the create response.

Deploy files¶

PUT /api/v1/pages/{slug}/deploy uploads files to the page. It replaces all existing files. Treat each deploy as a complete snapshot, not as an incremental update.

curl -X PUT "https://app.sweatstack.no/api/v1/pages/myapp/deploy" \
    -H "Authorization: Bearer {your_access_token}" \
    -F "files=@dist/index.html" \
    -F "files=@dist/app.js" \
    -F "files=@dist/styles.css"

Send one files part per file. SweatStack keeps file paths relative to the deploy root, so dist/assets/logo.png is served at https://myapp.pages.sweatstack.dev/assets/logo.png.

The API returns the page, now with published: true. If the page does not exist, it returns 404. Create it first with Create a page.

Delete a page¶

DELETE /api/v1/pages/{slug} deletes the page and all its files.

curl -X DELETE "https://app.sweatstack.no/api/v1/pages/myapp" \
    -H "Authorization: Bearer {your_access_token}"

The API returns {"ok": true} on success. The slug becomes available again.

Errors¶

Status	Cause
400	The slug is invalid, reserved, or already taken.
403	The token doesn't belong to the application's owner.
404	The page or the application does not exist.