To get the most out of your Sinch account, it is important to structure your resources in a way that aligns with your business goals. By utilizing Projects and Subprojects, you can create a secure, organized environment that simplifies billing, resource management, and access control.
Learn more about how the Sinch account model works.
Organizing with Projects
A Project is your primary container. Every Sinch account starts with a default project, which is often sufficient for standard needs. However, if your implementation grows, you may want to use additional projects to separate different parts of your business.
- Environmental Separation: The most common use for multiple projects is separating environments, such as creating one project for Development/Testing and another for Production. This ensures that testing activities never interfere with your live services.
- Organizational Separation: You can use projects to separate completely different internal departments or business units if they require distinct resource pools and user access.
Organizing with Subprojects
A Subproject sits inside a parent project and is a powerful tool for more granular organization. While they function technically like projects, they are designed for specific organizational workflows.
- The Reseller Model (Highly Recommended): If you are a reseller, the best practice is to create one Subproject per end-customer. This allows you to isolate the resources and costs for each client while maintaining a single parent project for your own overarching management.
- Automation: Because subprojects support specific API automation capabilities (like programmatic creation and deletion), they are the ideal choice for businesses that need to scale their customer or project onboarding automatically.
Key Factors to Consider
When deciding how to organize your activity, keep these three rules of the Sinch Account Model in mind:
- Access Inheritance: User access for the Build portal is managed at the Project level and inherited by all Subprojects within it. If two groups of users should never see each other's work, they should be in separate Projects.
- API Isolation: API credentials can be generated at the Subproject level. This ensures that an API key used for one specific end-customer or application cannot be used to access resources in another.
- Billing Roll-up: While you can view costs for individual subprojects, all costs ultimately roll up to the parent Project, and then to your single Account invoice.
Summary: Which should I use?
|
Use Case |
Recommended Structure |
|
Simple setup |
Use your single Default Project. |
|
Separating Dev/Prod |
Use two separate Projects. |
|
Reselling to Customers |
Use one Subproject per customer within a Project. |
|
Automating onboarding |
Use Subprojects (via API). |
