Docs
← Home Sign In Get Started

Overview

Shieldome's collaboration model is built around organizations - shared workspaces that give your entire team access to the same scan history, reports, and findings. Every scan run while an organization is active belongs to the org and is visible to all members with the appropriate role. Individual user accounts can belong to multiple organizations.

Creating an organization

  1. Go to Settings → Organizations.
  2. Click Create new organization.
  3. Enter an organization name (e.g. "Acme Corp Security Team") and an optional description.
  4. Click Create. You become the organization's first Admin.

After creation you land on the organization dashboard, where you can invite members and see all scans associated with the org.

ℹ️
A single Shieldome account can own or belong to multiple organizations. Scans run under the account that initiates them and count against that account's plan limits.

Inviting team members

  1. Open Settings → Organizations and select the organization.
  2. Click Invite Member.
  3. Enter the person's email address.
  4. Select their role (see table below).
  5. Click Send Invitation.

The invitee receives an email with a link to accept. If they already have a Shieldome account, clicking the link adds the organization to their account. If they don't, they're prompted to create a free account first. Pending invitations are listed in the Members tab with a "Pending" badge and can be cancelled at any time.

Roles and permissions

RoleCan do
Admin Full access: run scans, view all org scan results, download PDF reports, manage API keys, invite new members, remove members, change member roles, manage billing and subscription
Member Run new scans (results automatically belong to the org), view all org scan history, download PDF reports, manage own API keys. Cannot invite/remove members or change billing.
Viewer Read-only access: view scan results and finding details, download PDF reports. Cannot trigger new scans, modify findings, or manage any settings.
💡
Give Viewer access to stakeholders. Product managers, legal counsel, auditors, and clients can pull reports on demand with a Viewer account - without needing to involve your engineering team every time.

Organization dashboard

The organization dashboard is the shared home page for your team. It shows a consolidated view of all domains and scans associated with the org:

  • All domains - every unique target URL that has been scanned under this organization
  • Combined risk score - an aggregated risk score across all domains, weighted by severity and recency
  • Critical / High counts - how many open critical and high findings exist across all org targets right now
  • Member list - all current members with their roles and last-active timestamp
  • Recent activity feed - the last 20 scans run by any member, with who ran each and when

Admins see an additional Billing section showing scan activity by member, useful for capacity planning.

Shared scan history

All scans run while an organization is active appear in the org's shared Scan History, visible to every member. Members see each result labelled with the name of the user who triggered the scan.

Members with the Member or Admin role can also run new scans from the shared history view - the result is automatically attributed to the org, not their personal account.

Scan ownership and org mode

Scans you run within an organization context belong to the organization. To make sure a scan is attributed to the right org:

  1. Switch to the organization context using the org selector in the top navigation (if you belong to multiple orgs).
  2. Run the scan normally.

The scan will appear in the org's shared history immediately. Scans run under your personal account (i.e. outside any org context) are private to you and not visible to org members.

⚠️
Context matters. Double-check the org selector before running sensitive internal scans - a scan attributed to the org is visible to all members. If you need to test something privately first, switch to your personal account context.

Removing a team member

  1. Go to Settings → Organizations and select the organization.
  2. In the Members tab, find the user and click Remove.
  3. Confirm the removal.

Removed users immediately lose access to all org scans, reports, and settings. Their past scan contributions remain in the org history, attributed to their name, for audit purposes.

API reference

List organizations

GET /api/orgs
Returns all organizations the authenticated user belongs to, with their role in each.
bash
curl -H "X-Shieldome-Key: YOUR_API_KEY" \
  https://yourdomain.com/api/orgs

Create an organization

POST /api/orgs
Creates a new organization. The authenticated user becomes the first Admin.
json - request body
{
  "name":        "Acme Corp Security Team",
  "description": "Shared workspace for all vulnerability scanning"
}

Invite a member

POST /api/orgs/{org_id}/invites
Sends an invitation email to the given address. If the email belongs to an existing Shieldome user, they are added immediately with a pending-accept status.
json - request body
{
  "email": "[email protected]",
  "role":  "member"   // "admin" | "member" | "viewer"
}

Remove a member

DELETE /api/orgs/{org_id}/members/{user_id}
Removes a member from the organization immediately. Requires Admin role.
bash
curl -X DELETE \
  -H "X-Shieldome-Key: YOUR_API_KEY" \
  https://yourdomain.com/api/orgs/{org_id}/members/{user_id}

API keys and team access

API keys created by any Admin can be used by all team members for CI/CD integrations. Label each key with its purpose (e.g. GitHub Actions - production branch) so you can identify and rotate individual keys without disrupting unrelated pipelines. Go to Settings → API Keys to manage keys.

⚠️
Rotate keys when members leave. Any team member who has access to an API key can run scans and read all results. If a team member with key access leaves the organization, rotate the affected keys immediately.

Best practices for teams

  • Require 2FA for Admins - Security accounts with elevated access are a higher-value target. Enforce two-factor authentication for all Admin and Owner accounts at minimum.
  • Use one API key per pipeline - Label each key with the pipeline it belongs to. If a key leaks, you can rotate only that key without disrupting others.
  • Assign Viewer to stakeholders - Avoid giving Manager or Admin roles to anyone who only needs to read reports.
  • Set up webhooks for critical findings - Configure a Slack or Jira webhook (see the Webhooks guide) to alert the whole team when a critical vulnerability appears, not just the person who ran the scan.
  • Review the activity feed weekly - The org dashboard activity feed gives a quick snapshot of who is scanning what. Unexpected targets in the feed can indicate misconfigured CI jobs or unauthorized scanning.