Workspaces
A workspace is the top-level container for your entire organization in Storm. It holds all of your projects, members, settings, and billing information in one place. Key things to know about workspaces:- Every user belongs to at least one workspace. When you accept an invitation or create a new organization, Storm automatically places you inside a workspace.
- Each workspace operates independently. Projects, members, API credentials, and billing are all scoped to a single workspace and are not shared across workspaces. If you manage multiple organizations or environments (for example, a production workspace and a sandbox workspace), you switch between them from the account menu.
- Workspaces are identified by a unique slug. This slug appears in your workspace URL (e.g.,
app.storm.io/your-slug/) and in every API call you make. Choose your slug carefully — changing it later updates your URL and requires updating any hardcoded API base paths.
Projects
A project is the primary unit of work within a workspace. Think of it as a dedicated space where a specific team, product area, or workstream lives — with its own members, settings, and data, fully isolated from other projects in the same workspace. Key things to know about projects:- You can create as many projects as you need. There’s no limit on the number of projects within a workspace (subject to your plan tier), so feel free to create a project for each team, product line, or initiative.
- The same user can belong to multiple projects with different roles. A person might be a Member on most projects but an Admin on the one they own, or a Viewer on a sensitive project they’re only monitoring. Role assignments are per-project, not global.
Project-level role overrides take precedence over workspace-level roles. A user who is a Viewer at the workspace level can be granted Admin access on a specific project.
Members and roles
Every person you add to Storm is assigned a role that determines what they can see and do. Storm ships with three built-in roles that cover most organizational needs.| Role | Description |
|---|---|
| Admin | Full access to workspace settings, billing, and all projects. Can invite and remove members. |
| Member | Can create and manage projects they belong to. Cannot access billing or workspace-level settings. |
| Viewer | Read-only access to projects they are added to. Cannot create or modify content. |
Custom roles with granular permissions — such as restricting access to specific integrations or limiting data exports — are available on higher-tier plans. See Roles and Permissions for a full breakdown of what each role can do and how to configure custom roles.
API credentials
API keys allow external tools, scripts, and integrations to interact with your workspace programmatically. You create and manage them from Settings → API. Key things to know about API credentials:- Each key is scoped to a specific workspace. A key created in your production workspace cannot access data in a separate staging workspace.
- Keys can be restricted to read-only or read-write access. Use read-only keys for observability tools, dashboards, and reporting integrations that only need to pull data. Reserve read-write keys for integrations that need to create or modify resources.
- Authenticate every REST API request with your key. Pass your workspace-scoped API key in the
Authorizationheader as a Bearer token on all requests to the Storm REST API. - Webhook deliveries are signed with HMAC-SHA256. When Storm sends a webhook
POSTto your endpoint, it includes anX-Signature-256header containing an HMAC-SHA256 signature of the request body. Always verify this signature before processing the payload to confirm the request originated from Storm. - Integration connectors use OAuth 2.0. When you connect a third-party service through Storm’s integration catalog, Storm initiates a standard OAuth 2.0 authorization flow. You authorize access in your browser, and Storm stores the resulting token securely — you never handle the OAuth token directly.
- Treat API keys as secrets. Never commit them to source control, include them in client-side code, or share them in chat. If a key is ever exposed, rotate it immediately from the Settings → API page — Storm lets you regenerate a key without downtime by issuing a new key before revoking the old one.