Working with projects and services
The combination of projects and services offers you flexibility to support many of the different use cases for access control, billing, and configuration of products and usage.
Note:
If you only have one use case, or have one team which is operating within one country, it's likely that you may not need the additional flexibility and complexity that comes with setting up multiple projects and services, and continue using the default created project and the default created services in each product.
Services
Fax API has a default service created for you when you create an account or a new project. A service is owned by a project, and you can have one or more services for each product, where each product service can have different things you can configure on it. You can control what service to use by adding the serviceId field to your API call, and if you don't supply it the default service for that product will be used.
Services enable you to configure default feature sets for a use case or a group of numbers. For example, you can put all European numbers in a service and configure the incoming traffic URL to use your European data center. Another use case would be if you want to have fine-tuned control of timeouts for delivery on Verifications or set priority for delivery within your different use cases, but you don't want to or can't separate data. You may still want your backend to compare data across the feature set for delivery, or you want to be able to move numbers between different configurations. Or perhaps you are part of a single team working on all Sinch-related services and want to see the an overall health view in the dashboard across all use cases.
Services are also a great way to enable or disable features with out having to redeploy in production.
Everyone that has access to a project will have access to all services within that project.
Important!
A service is not concerned with access control features; you would use the project API keys to configure access control.
Comparison
Below you can see a comparison table
| Projects | Sub accounts | Services | |
|---|---|---|---|
| Who is it for | Everyone | ASP/ISV | Everyone |
| Who need many | Enterprise with the need to separate access control and data separation between brands or teams | ASP/ISV | Enterprises with one or more use cases, enterprises with more than one number will still benefit of group configuration |
| When to use it | When you need access control and resource separation between environments, teams etc. A project can have a balance | Track usage per customer | Load balancing between data centers for incoming traffic, configure default features per use case on same product for a group of numbers. Traffic priority control |
| How's it billed | Each project have a billing account, can be shared across projects | Billed on the project, as a separate row | Services are not a container to separate billing |
| Where is managed | UI only? | UI and API | UI and API |
| Where is it mostly used | UI | API | UI |
