Auth profiles store browser authentication state for capture requests. They are useful for dashboards, internal tools, and staging apps that require login.

Endpoints

MethodPathPurpose
GET/v1/auth-profilesList auth profiles.
POST/v1/auth-profilesCreate an auth profile.
PATCH/v1/auth-profiles/{id}Update an auth profile.
POST/v1/auth-profiles/{id}/testTest profile against a URL.
DELETE/v1/auth-profiles/{id}Delete a profile.
bash
curl -X POST "https://screenframed.com/v1/auth-profiles" \ -H "Authorization: Bearer $SCREENFRAMED_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "name": "Production dashboard", "domain": "app.example.com", "cookie_header": "session=..." }'

Create with browser storage state

For most real workflows, use the CLI:

bash
screenframed auth login --url https://app.example.com/login --project prj_...

The CLI captures cookies and localStorage from a real browser session and sends them to the auth profile API.

Use in a capture

json
{ "url": "https://app.example.com/dashboard", "auth_profile_id": "ap_01K...", "project_id": "prj_01K..."}

Limits and matching

  • Auth profiles are matched by domain.
  • Profiles can be scoped to a project.
  • Cookie and storage inputs are normalized and size-limited.
  • Delete profiles when credentials no longer need to be used for captures.
Ask a question... ⌘I