Choosing an integration
There are three ways to put DialStack in front of your customers. They differ in how much of the experience you build and how much DialStack provides. All three run on the same accounts, users, numbers and webhooks, so you can start with one and add another later.
| White-label portal | Embedded SDK components | Direct API | |
|---|---|---|---|
| What your customers use | A DialStack-hosted portal with your branding, on your own domain if you like | Phone features inside your own app | Whatever you build |
| What you build | Account creation and user sync from your backend, and a link to the portal | A backend route that mints session tokens, and the screens the components sit in | Your UI and the backend logic behind it |
| What DialStack provides | The whole portal: admin tools, call history, voicemail, devices, sign-in | Prebuilt React and Web Components, with data loading, paging and token refresh | The REST API, webhooks, the event stream, WebRTC and audio streaming |
| Credentials you handle | Your secret API key, on your server | Your secret key on the server, and short-lived session tokens in the browser | Your secret key, plus session or user tokens for anything that runs on a device |
White-label portal
Pick this when:
- You want phones live in weeks, not months.
- You don't have front-end capacity for a phone surface.
- Your customers are used to signing in to vendor portals (payroll, scheduling, dealer management tools).
Pick something else if phone features have to live inside your app's main workspace, with no switch to another site.
Continue with White Label.
Embedded SDK components
Pick this when:
- Calling lives inside a workflow your users already work in every day, such as a CRM, a dispatch board or an EHR.
- You want to control layout and navigation, but not build call history, voicemail or number management from scratch.
- You have a React or modern web front end.
Pick something else if your customers would rather have a dedicated phone portal, or if the experience you need doesn't match any of the prebuilt components.
Continue with the SDK overview.
Direct API
Pick this when:
- You're building a voice experience of your own, such as an AI call center, a dispatcher console or a live agent assistant.
- You need fine-grained control over call routing, audio streaming or event handling.
- You have the engineering capacity and want nothing between your code and the platform.
Pick something else if you need a full phone-system portal without front-end work, or phone features inside your UI without building custom flows.
Continue with Making requests and the API reference.
Mixing paths
The paths share one platform, so they combine. A common pattern is the white-label portal for administrators, with embedded components or your own API-driven screens for the people who take calls every day. Everything you provision through the API shows up in the portal, and the reverse.
See also
- Architecture overview: accounts, users, routing and the four ways your app talks to DialStack.
- Authentication: API keys, session tokens and user tokens.
- Quickstart: your first account and user.