Authenticated Pages

Auth profiles let ScreenFramed load a private page with stored browser cookies and localStorage. Use them for product dashboards, staging apps, admin panels, and customer-specific views.

Create an auth profile with the CLI

bash
screenframed auth login \  --url https://app.example.com/login \  --project prj_01K... \  --name "Production dashboard"

The CLI opens a real browser. Log in normally, return to the terminal, and confirm. ScreenFramed stores the captured browser state server-side and returns an ap_... profile id.

Use an auth profile

json
{  "url": "https://app.example.com/dashboard",  "project_id": "prj_01K...",  "auth_profile_id": "ap_01K...",  "device": "browser-macos",  "background_style": "none"}

Test a profile

Use the CLI before wiring the profile into a batch job:

bash
screenframed auth test ap_01K... --url https://app.example.com/dashboard

Or call the API:

bash
curl -X POST "https://screenframed.com/v1/auth-profiles/ap_01K.../test" \  -H "Authorization: Bearer $SCREENFRAMED_API_KEY" \  -H "Content-Type: application/json" \  -d '{ "url": "https://app.example.com/dashboard" }'

Domain matching

Auth profiles are matched by domain. A profile for app.example.com can be used for that host and compatible subpaths. Keep separate profiles for production, staging, and local tunnel domains.

Refresh a profile

bash
screenframed auth refresh ap_01K... --url https://app.example.com/login

Refresh when cookies expire, the login flow changes, or the profile starts failing tests.

API management

Use Auth Profiles API when you need to create profiles from cookie headers or browser storage state in your own backend.

Auth profiles contain sensitive browser state. Scope them to projects, delete them when no longer needed, and avoid using broad admin accounts for routine screenshot generation.