Concepts

Projects

Projects are the top-level container for your MUDBASE resources. Every API key and resource is scoped to a project.

What lives inside a project

Everything you build with MUDBASE — collections, buckets, functions, realtime channels, webhooks, wallets, and the API keys that authenticate requests — belongs to exactly one project. Projects sit inside an organization, and an organization can have multiple projects (for example, one per environment or one per app).

Data does not cross project boundaries: a collection created in one project is never visible from another, even within the same organization. This is the same isolation an API key relies on — a key issued for Project A cannot read or write Project B's data, regardless of which permissions the key was granted.

Creating a project

Create a project from the Console (Projects → New Project). You'll set a name and an optional description; MUDBASE generates a URL-safe slug used in API paths and your project's base URL.

Every request to a project-scoped endpoint includes the project ID in the path, for example:

text
GET https://api.mudbase.dev/api/projects/{projectId}/collections/{collectionId}/data
GET https://api.mudbase.dev/api/projects/{projectId}/collections/{collectionId}/data

Project settings

Each project has its own settings, independent of other projects in the same organization:

  • requireEmailVerification — whether end-users must verify their email before signing in
  • requirePhoneVerification — same, for phone/SMS verification
  • defaultUserAccountStatus — the status newly-registered end-users start with (active by default)
  • Custom domain / API base URL, if your plan includes it (see the Domains page in the Console)

Update these from Console → Settings → Organization → Project, or via the project update API endpoint.

Plan limits are per project and per organization

Some limits apply per project (buckets, collections, webhooks, functions, API keys), while others apply across your whole organization (total storage, total projects, team members). The Console's Usage page shows both, and any page where you're about to hit a limit shows a notice explaining which one and what to do about it.

Tip
Use separate projects for separate environments (e.g. a "staging" and a "production" project) rather than separate organizations — this keeps billing and team access in one place while still fully isolating each environment's data.

Deleting a project

Deleting a project permanently removes its collections, files, and configuration. This cannot be undone. API keys issued for a deleted project stop working immediately.

See API Keys for how keys are scoped to a project, or Authentication for how project scoping interacts with request auth.