Is ZITADEL suitable for a white-label B2B2B SaaS architecture?
I’m exploring whether ZITADEL is a good fit for a SaaS with a B2B2B architecture structured like this:
Organization A
– Subaccount 1
– Subaccount 2
– Subaccount 3
Organization B
– Subaccount 1
– Subaccount 2
– Subaccount 3
Each top-level organization would manage multiple subaccounts, almost like nested tenants. Also each org will have his own custom domain and branding.
I’m wondering if ZITADEL can actually handle this, or if I’m overthinking it. A few quick questions:
- Is a nested sub‑account architecture (org with sub‑orgs) something ZITADEL is designed for?
- Or is it better to treat each sub‑account as its own organization in ZITADEL?
- What about letting a parent org manage its subaccounts users or policies? Are project or user grants a good fit for this?
I read that ZITADEL supports multi‑tenant B2B use cases like creating separate organizations per customer, using project grants for delegation, allowing orgs to manage branding, SSO, roles, etc.
But I’m unsure how well that maps to an architecture with subaccounts under a parent org.
Has anyone implemented a similar setup or can point me to patterns or best practices for this?
Thanks for any insight!
Organization A
– Subaccount 1
– Subaccount 2
– Subaccount 3
Organization B
– Subaccount 1
– Subaccount 2
– Subaccount 3
Each top-level organization would manage multiple subaccounts, almost like nested tenants. Also each org will have his own custom domain and branding.
I’m wondering if ZITADEL can actually handle this, or if I’m overthinking it. A few quick questions:
- Is a nested sub‑account architecture (org with sub‑orgs) something ZITADEL is designed for?
- Or is it better to treat each sub‑account as its own organization in ZITADEL?
- What about letting a parent org manage its subaccounts users or policies? Are project or user grants a good fit for this?
I read that ZITADEL supports multi‑tenant B2B use cases like creating separate organizations per customer, using project grants for delegation, allowing orgs to manage branding, SSO, roles, etc.
But I’m unsure how well that maps to an architecture with subaccounts under a parent org.
Has anyone implemented a similar setup or can point me to patterns or best practices for this?
Thanks for any insight!
