Client Hierarchy Structure
From the Claude.MD context, we know Ipster is designed to support multi-level client structures for future reseller access. This section will document how organizations are structured and managed.TODO: Organization Data Model
Team Input Needed: We need to document the actual client/organization structure in our database
- What’s the exact hierarchy? (Ipster → Client → Subcompany → Location?)
- What fields does each level have? (name, billing_info, settings, etc.)
- How do we handle billing relationships between levels?
- What permissions flow down the hierarchy?
TODO: Client Types and Permissions
Questions for the team:- What are the different client types? (Billing client, reseller, end customer?)
- What can each client type access?
- How do we handle data isolation between clients?
- Do clients have different feature flags or limits?
TODO: Multi-Tenant Architecture
Questions for the team:- How do we ensure data isolation between clients?
- How are agents assigned to clients/organizations?
- Can clients share agents or are they always isolated?
- How do we handle client-specific branding/customization?
TODO: Available Endpoints
Once we confirm what endpoints exist, we’ll document:GET /v1/clients- List client organizationsPOST /v1/clients- Create new clientGET /v1/clients/{id}- Get client detailsPUT /v1/clients/{id}- Update clientGET /v1/clients/{id}/subcompanies- List subcompanies (if applicable)POST /v1/clients/{id}/subcompanies- Create subcompany (if applicable)
TODO: Client Onboarding Flow
Questions for the team:- What’s the process for onboarding a new client?
- What default settings/agents do new clients get?
- How do we handle initial billing setup?
- What’s the approval process for new clients?
TODO: Future Reseller Support
Questions for the team:- What’s the long-term vision for partner/reseller access?
- What additional API permissions will resellers need?
- How will white-labeling work?
- What reporting/analytics will resellers have access to?