mailnix Docs
    mailnix / Projects

    Core concepts

    Projects

    Every workload resource in mailnix lives in exactly one project inside your organization: forms, destinations, routing rules, failover policies, email templates, traces, inbound routes, SMTP credentials, API keys, publishable keys, virtual inboxes, and webhook endpoints.

    Think of a project as a workspace boundary. An AI agent session binds to one project when you approve the OAuth consent page (anonymous bootstrap sessions get a fresh sandbox project); the dashboard's top-bar switcher selects your active project. Both views show the same thing: what an agent creates in project X is what you see in the dashboard with project X selected.

    The default project

    Every organization has one project named "Default". It cannot be deleted, and resources created without explicit project attribution belong to it.

    Attribution and filtering

    • REST list endpoints take an optional ?project=<id> filter (for example GET /v1/forms, GET /v1/inboxes); without it you get the org-wide list.
    • REST create bodies accept project_id; POST /v1/messages accepts project_id to attribute a send.
    • GraphQL list queries take a projectId argument, create inputs accept projectId.
    • MCP tools need neither: the session's bound project is the attribution.

    Send budgets

    Each project can carry a daily send budget, set on the dashboard's Projects page. The budget is enforced at send time for every send attributed to the project, from any surface. An exhausted budget refuses the send with HTTP 429 and code project_budget_exhausted; refused sends do not consume budget. An unset budget means no per-project cap (plan limits still apply).

    Moving resources

    The dashboard (and the GraphQL mutation moveResourceToProject) moves a form, template, inbound route, SMTP credential, virtual inbox, webhook endpoint, or destination to another project in the same organization. Destinations move only while no routing rule or failover policy references them; org-wide destinations and traces never move.

    What is organization-wide by design

    The project switcher never filters these: suppressions (a bounced address is bounced for every project), sending domains and sender identities, bounce sources, members and roles, and billing. Projects are never a billing boundary; the per-project usage breakdown on the billing page is reporting only.

    Multi-tenant SaaS

    If you send on behalf of your own end-customers, see Sub-projects for per-tenant partitions with their own quotas and webhook payload attribution.