How projects work
The default “Production” project
Every org starts with one project, and it is the implicit one:- Its slug is
default. - Its display name is Production.
- Any request that doesn’t specify a project resolves to it.
Isolation
Projects are isolated end to end:- Ingest: events, traces, and signals are stored against the project they were sent to.
- Dashboards and analytics: the dashboard scopes everything (events, conversations, issues, stumbles) to the selected project.
- AI features: topic classification, signals, Tiny Models, and the Triage Agent operate per project, so a model trained in one project doesn’t leak into another.
The Triage Agent can be scoped to the All projects view.
The All projects view
The project switcher includes an All projects entry. Selecting it reads across every active project in the org at once (archived projects are never included), while keeping each row attributed to the project it belongs to:- Org-wide reads. Events, conversations, users, issues, and the other read surfaces aggregate all active projects instead of one.
- Per-project attribution. Every row is labeled with its owning project, so you can always tell where a result came from.
- Click-through. Opening a row from the org-wide view takes you into the owning project’s scope, with a way back to All projects where you left off.
- Creating picks a target. The view aggregates reads; it doesn’t blur ownership for writes. Creating something project-scoped from it (a signal, an alert, and so on) first asks which project it should live in.
Zero-data-retention behavior does not change in the All projects view. ZDR sanitization applies to ZDR-ingested events only: an event ingested through the ZDR Signals surface persists as a sanitized identity shell and stays sanitized in every scope, while events ingested through the standard pipeline keep their stored content wherever they are shown.
Backward compatibility
Projects are fully backward compatible. Orgs that never set a project keep sending to thedefault project, and every existing query, dashboard, and SDK call behaves exactly as before. You only opt in to multi-project behavior by creating additional projects and sending their slugs.
Roles and permissions
- Creating, renaming, and archiving projects is restricted to Owner and Admin roles.
- Members can send data to and view existing projects, but cannot manage the project list.
Using projects
Set a project
You select a project per request by sending its slug. The canonical contract is theX-Raindrop-Project-Id HTTP header; each SDK also exposes an option that sets this header for you.
When the slug is omitted, empty, or
default, the request resolves to the Production (default) project, identical to not specifying a project at all.projectId when constructing the client:
@raindrop-ai/browser-sdk) accepts the same projectId option.
Python — pass project_id to raindrop.init(...):
Read across all projects
Both the Query API and the MCP tools accept* as the project (via the X-Raindrop-Project-Id header, the SDK’s projectId option, or an MCP tool’s project argument) to read across all active projects, with each row tagged by its owning project_id. * works only on endpoints that support it (others return a 400), and narrowing to a subset with project_ids is Query API-only.
Create a project from ingested data
You don’t have to create a project before you send data to it. When you send events with a new slug your org hasn’t used yet, Raindrop accepts them and stores the data under that slug, up to a per-org limit on slugs that don’t yet have a project. Each such slug then appears in Settings -> Projects under “Projects with data, not yet created”, along with how many events it has received and when it was last seen. An Owner or Admin can select Create project there to create it. The data only becomes visible in the dashboard and the Query API once the project has been created. This lets you start sending from a new slug in your code first and create the project in the dashboard afterward, without losing the data sent in between.Archive a project
Projects can be archived when you no longer need them. There is no hard delete yet.- Archiving hides a project from the dashboard and stops it from accepting new data.
- Archived slugs are not reusable: you can’t create a new project that reuses an archived project’s slug.
- Data sent to an archived project is rejected with a
403. See Ingest behavior. - The
defaultproject cannot be archived.
Reference
Identifiers
Each project has two identifiers:Ingest behavior
What happens to data you send on ingest:
Reads are stricter than writes: the dashboard and Query API only return data for a project that exists and is active, so an unknown or archived slug returns a
403 on read.
Event views are finalized-only, so events sent via
trackAiPartial / track_partial appear once they finalize, not while still pending. This is independent of projects. See Core Concepts.Troubleshooting
My events aren’t showing up in the dashboard. If you sent them to a brand-new slug, the project isn’t created yet. The data is stored but stays hidden until an Owner or Admin creates the project in Settings -> Projects. See Create a project from ingested data. Ingest is returning a403. The slug is either archived or your org has hit the per-org limit on uncreated slugs. Create the pending projects (or stop sending to unused slugs) and retry. See Ingest behavior.
Ingest is returning a 400. The slug is malformed. It must be at most 63 characters, lowercase letters, digits, and hyphens, and start and end with a letter or digit. See Identifiers.
Data landed in the wrong project. The X-Raindrop-Project-Id header (or the SDK’s projectId / project_id) didn’t carry the slug you expected. An omitted, empty, or default value always resolves to Production.