Platform Settings
The platform settings page shows your DialStack platform configuration, including status and API keys.
Viewing Platform Information
Navigate to your platform from the sidebar (the platform name appears in the navigation for platform admins). The platform detail page shows:
- Handle — Your platform's unique identifier
- Status — Whether the platform is Active, Suspended, or Cancelled
- Publishable Key — The public API key used in client-side SDK integrations
- Created — When the platform was created
Managed VoiceAI
The Managed VoiceAI toggle controls whether the built-in Managed VoiceAI agent is offered to your accounts when they create a voice app. Turn it off if your platform provides its own AI experience and you don't want the built-in agent shown to your customers.
When the toggle is off:
- The Managed VoiceAI option no longer appears when creating a voice app, and its documentation is hidden from your branded help. Custom (webhook) voice apps are unaffected.
- Any managed agents that already exist keep working and stay editable — turning the setting off never strands existing configuration.
This is the platform-wide default. You can override it for an individual account from that account's settings (see Managing Accounts).
Default Service Subscription Agreement
Your platform has a default Service Subscription Agreement — Standard, or Healthcare (HIPAA) for customers handling protected health information — shown on the platform's Service agreement card. Accounts you create start on it, and you can change any individual account before its customer accepts (see Choosing the Service Subscription Agreement).
Only a DialStack super admin can change the default, because selecting the healthcare agreement commits DialStack to a Business Associate Agreement for the accounts created under it. Contact support if your platform's default is wrong.
Your platform is also cleared for a specific set of agreements, and can only put a customer on one of them. If an agreement is not offered when you create an account, your platform is not cleared for it. Being cleared for an agreement is a contractual step between DialStack and your platform, so adding one is a conversation with your account contact rather than a settings change. A platform cleared for exactly one agreement sees it stated rather than offered as a choice.
Changing the default affects only accounts created afterwards. Accounts that already exist keep the agreement they were created with, and their customers' existing acceptances stay valid.
Help center URL
The Help center URL field, in the Branding section, points your customers at your own help content instead of the help built into the portal; leave it blank to keep the built-in white-label guide.
When you save a URL here:
- The Help entry in the account menu opens your help center in a new tab, rather than the built-in guide.
- The ? button on each page stops appearing, along with the panel of page-specific help it opens. Anywhere else in the portal that links to a specific guide page stops offering that link.
- The built-in guide's own pages stop being reachable inside the portal.
Three things worth knowing before you set it:
- It takes effect as soon as you save, so set it only once your own help content is published. Setting it earlier leaves your customers with no help in the portal and a link they cannot open.
- It applies to everyone who signs in on your subdomain, your own staff included.
- It is a single destination. There is no per-page mapping, which is why the page-specific ? button goes away rather than pointing somewhere else.
Clearing the field puts the built-in guide and page-specific ? buttons back.
Customer ordering
Once hardware ordering is available to your platform, the Customer ordering card has your customers approve the hardware orders you build for them before they're placed:
- Require customer approval for hardware orders turns it on. It needs an Approval threshold: an order above it also needs your approval. Sending an order to the customer counts as your approval.
- Show customers prices shows customers each unit's price with your Markup (%) added, and shipping at cost. With it off, customers see no prices.
API Keys
Your platform has two types of API keys, each with a live and a sandbox variant (see Sandbox vs live keys for what each variant does):
- Publishable Key — Safe to include in client-side code. Used to initialize the DialStack SDK.
- Secret Key — Must be kept confidential. Used for server-to-server API calls. This key is only shown once, at platform creation or when you rotate keys.
Click the copy icon next to any key to copy it to your clipboard.
Webhook Secret
The Webhook Secret is separate from the Secret Key. It is used to sign webhook deliveries so your receiving endpoint can verify that a webhook actually came from DialStack and hasn't been tampered with. It is not an API key and cannot be used to call the API.
In short:
- Secret Key — authenticates your calls to our API.
- Webhook Secret — lets you authenticate our calls to your webhook endpoint.
Account-scoped webhook endpoints
A webhook endpoint is normally platform-wide: it receives events for every account in its mode (live or sandbox). You can instead register endpoints scoped to a single account, so a dedicated receiver gets only that account's events.
Account scoping is additive: an account-scoped endpoint receives its account's events in addition to your platform-wide endpoints — it does not remove those events from the platform-wide delivery. This is useful when one account (for example a staging or demo account) needs its events delivered to a separate URL, without that receiver ever seeing any other account's events.
Manage an account's webhook endpoints from that account's page (Webhook
Endpoints, on the General tab). This section is available to platform
administrators only. Over the API, include the DialStack-Account header on the
webhook-endpoint calls to manage a specific account's endpoints; omit it to
manage your platform-wide endpoints.
Tracking billable changes
DialStack can notify your systems whenever an account's user or phone
number count changes, so you can reconcile before an invoice arrives instead of
after. Subscribe a webhook endpoint to user.created, user.deleted,
phone_number.activated, and phone_number.disconnected; each notification
names what changed and the billable count either side of the change.
Two things to keep in mind:
- These are resource counts, not invoice amounts. Billing is prorated, so a user added mid-period is charged only for the remainder of that period. The counts tell you what is in service, not what you owe.
- Who made each change comes from the audit log, not the notification itself, so that permissions are applied consistently. Each notification carries a correlation ID you can look up in the audit log to see the person responsible. For phone numbers, look up the order instead — a number goes into service when the upstream provider confirms it, so the change itself is not attributed to a person.
See Webhook Events for the notification format and the audit-log lookups.