v0.4 — Team management
Invite teammates, assign roles (owner / org_admin / member / viewer), and see per-key spend by member. Single-org-per-user enforced at the database; one team per user within that org, by design.
You shouldn't share an API key over Slack. v0.4 ships team management: invite teammates, assign roles, and see exactly which key spent which dollars.
Four roles, scoped at org + team
| Role | Can do |
|---|---|
| Owner | Everything, including billing, transfer ownership, delete the org |
org_admin | Manage keys, guardrails, prompts, budgets, invite + remove members. Cannot touch billing. |
| Member | Create + rotate their own virtual keys, view org analytics, run the playground |
| Viewer | Read-only across the dashboard — useful for finance, security, exec stakeholders |
Roles map cleanly to four levels under the hood — owner, org_admin, member, and viewer. One UUID, one source of truth.
Tenancy is org → team → member
Per Rule #26, every user belongs to exactly one organization AND exactly one team within that org. Every org auto-provisions a Default team at creation. Multi-team membership per user is intentionally out of scope until customer demand emerges — the path to "change teams" is leave + rejoin.
This sounds restrictive; it's a deliberate simplification. Spend attribution, RLS policies, and budget enforcement all become unambiguous when a user has exactly one team identity.
Invitations
Owners and admins send invites from /{org}/team:
- Email + role + optional target team (defaults to the inviter's team)
- One-time link, 7-day expiry, single-org-per-user enforced at accept time
- Audit-trail entry on every accept / decline / expire
# Or via the API, if you're scripting onboarding
curl -X POST https://app.nrouter.ai/api/supabase/invitations \
-H "Content-Type: application/json" \
-H "Cookie: <your-session-cookie>" \
-d '{ "email": "alice@acme.com", "role": "org_admin" }'Per-virtual-key spend (v0.3) tells you which member is driving cost. Per-team budgets (v0.5 follow-up) let you cap it.
Platform release verification & compatibility standards
All nRouter release notes reflect changes deployed across our global edge routing infrastructure. Below is our baseline deployment architecture and verification criteria.
Zero-Downtime Rolling Delivery
Releases deploy via immutable container digests with automated health verification. Existing streaming responses complete uninterrupted while new requests seamlessly route to updated instances.
Drop-In API Backward Compatibility
Our interface remains strictly compatible with standard OpenAI client SDKs and wire formats. Enhancements degrade gracefully or fail open with explicit error reporting to protect calling workloads.
How can engineering teams verify capabilities in this release?
Teams can inspect currently supported capabilities and active model deployments programmatically via the authenticated /capabilities endpoint, or review live latency profiles at /models.
Where can edge cases or regressions be reported?
If your team experiences unexpected response behavior, report the issue with the relevant x-nr-request-id header to support@nrouter.ai or via the community Slack at /community.