Skip to main content
Access in Blindsight has three layers that combine: workspace roles, per‑project membership, and API keys for programmatic access. This page covers all three.

​
Roles

​
Built‑in workspace roles

​
Custom roles

Admins can define custom roles from a granular permission catalog. A custom role is just a named bundle of permissions.

​
Per‑project access

In addition to the workspace role, projects can have their own member lists. A workspace Member can be a project Admin inside one specific project. Workspace roles are the floor; project roles are the ceiling.
Use this pattern to give a contractor Viewer access at the workspace level and Reviewer access inside one project, without exposing them to the rest of your data.

​
Invitations

1

Invite a user

From Settings → Users → Invite, enter the email and pick a role.
2

They accept

The invitee gets an email with a one‑click acceptance link, sets a password, picks a display name, and lands in the workspace with the role you assigned.
3

Manage pending invites

Pending invitations show on the Users page. Resend or Revoke at any time. Invitations expire after a configurable window (set under Settings → Security).

​
Reviewers

Reviewers are a specialised subset used by the triage workflows. They can be:
  • Mentioned in result comments (@reviewer-name).
  • Assigned specific findings for review.
  • Listed as approvers on a healing run (where required by policy).
You don’t have to use Reviewers, workspace Admins and Members can do the same things, but they’re a useful designation when triage is someone’s main job.

​
User profile (/profile)

Every user has their own profile page with:
  • Display name and avatar.
  • Email and password reset.
  • Notification preferences (per event type, per channel).
  • Active sessions and a “sign out everywhere” button.

​
API keys

Everything in the UI is also available via the REST API. To use it programmatically, mint a key.

​
Creating a key

1

Open Settings → API Keys

Click New key.
2

Name and scope

Give it a descriptive name (CI pipeline, Lab upload script). Pick scopes:
  • Read‑only, can list and read but not mutate.
  • Upload dataset, can ingest data.
  • Full, mirrors your workspace permissions.
Or compose a custom scope from the permission catalog.
3

Set an expiration

Never, 30 days, 90 days, 1 year. Short‑lived keys are safer; mint a new one when this one expires.
4

Copy the token

Now. The token is displayed exactly once. If you miss it, revoke and mint a new one.

​
Using the key

Pass it as Authorization: Bearer <token> on every API call.
You can do everything via the API:
  • Upload datasets (POST /api/uploads/*).
  • Launch scans (POST /api/datasets/{id}/scan).
  • Poll progress (GET /api/scans/{id}).
  • Stream live progress (WS /ws/api/scans/{id}).
  • Trigger healing (POST /api/datasets/{id}/cure).
  • Generate compliance reports (POST /api/compliance/reports/*).
  • Manage Playground sessions, custom rules, schedules, projects, webhooks.
See the API reference for the full schema.

​
Revoking a key

From Settings → API Keys, click Revoke on any row. Revocation is instant and audit‑logged. Subsequent calls using the revoked key return 401.

​
Rotation best practices

Mint one key per pipeline. Rotate every 90 days. Store the new value in your CI’s secret manager, run jobs against both old and new for one rotation window, then revoke the old one.
Mint with Never expiry and rotate manually on a cadence. Tag the key with the service name so it’s obvious in the audit trail.
Mint a short‑lived key (30 days), use it, revoke when done. Treat ad‑hoc keys like one‑use tokens.