SweatStack Pages¶

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 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 settings page at 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. When the deploy succeeds, the CLI prints a link to the publish flow. If the Page does not exist, the deploy fails with 404.

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

2. Write a one-sentence description¶

Pages apps run entirely in the user's browser. There's no server holding tokens or processing user data, so SweatStack supplies a privacy policy, a logo, and a URL for you. You write a short description (one or two sentences), and your app is public.

You'll find it behind Go live in one click at the top of the app's settings page while the app is private, or through the link the CLI prints after a successful deploy.

3. Confirm eligibility¶

The lighter publish path 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 through the self-hosted publish flow instead.

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 requires the data:write scope, except reads, which require data:read. 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": false
    },
    "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.

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.