Skip to content

SweatStack Pages

Building a server-side OAuth app instead?

Apps you host yourself follow a different publish path with a few 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 (storing data, holding secrets, running background jobs), use Going live instead.

A SwetStack Pages app is the same OAuth2 application as any other; it just gets a simpler publish path because the platform 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

Use the CLI:

sweatstack page deploy myapp ./dist

This creates a Page (if it doesn't exist) and uploads your ./dist directory. The CLI prints a link to the publish flow when the deploy succeeds.

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, logo, and URL for you. You provide a short description (one or two sentences) and your app is public.

You'll find the publish flow on the app's settings page, or via the link printed after a successful deploy.

3. Confirm eligibility

The lighter publish path applies only to genuine 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 non-Pages redirect URIs, 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. Choose what to expose: public vs. listed

Public means anyone can connect. Listed means your app additionally appears in the public Apps directory. The two are independent settings. See Going live › Choose what to expose for the breakdown.

Review and API guidelines

The same rules apply as for self-hosted apps: continuous asynchronous review, and a baseline of 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, multipart upload, and file collection in one command. The HTTP API below exists for cases the CLI doesn't fit: CI/CD in a different language, custom tooling, or deploying from a serverless function.

Authentication

Pages endpoints authenticate as the principal user: the user who owns the application. Use your personal API key or an OAuth token issued to you, not an application token issued via OAuth2 to a third-party app.

All endpoints require the data:write scope (read uses data:read). Get an API key at Settings → API.

Create a page

POST /api/v1/pages registers a new 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"

Returns:

{
    "slug": "myapp",
    "published": false,
    "application": {
        "id": "app_...",
        "name": "My App",
        "is_private": false
    },
    "url": "https://myapp.pages.sweatstack.dev"
}

The slug is lowercased and validated against reserved words. If it's taken or invalid, the response is 400. Pages start unpublished; deploying files publishes them.

Get a page

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

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

Same response shape as create.

Deploy files

PUT /api/v1/pages/{slug}/deploy uploads files to the page. This replaces all existing files: treat each deploy as an atomic snapshot, not 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"

Multiple files parts can be included in a single request. File paths in the upload are preserved relative to the deploy root, so dist/assets/logo.png lands at https://myapp.pages.sweatstack.dev/assets/logo.png.

Returns the page metadata (now with published: true).

Delete a page

DELETE /api/v1/pages/{slug} removes the page and all its assets.

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

Returns {"ok": true} on success. The slug becomes available for reuse.

Errors

Status Cause
400 Slug invalid, reserved, or already taken
403 Token doesn't belong to the application's owner
404 Page or application not found