Security
Keys
- Keep keys on your servers, in a secret store. Never put a key in a browser, mobile or desktop app, in source code, in a URL or in a log line.
- Give each integration its own API client with only the scopes it needs.
- Set an IP list on each API client when your servers have fixed addresses.
- Rotate keys regularly, and at once if one may have been exposed. A key sent in a URL is refused and must be treated as exposed.
Transport
The API is served over HTTPS only. Responses carry Cache-Control: no-store. The API sends no CORS
headers: it cannot be called from a web page.
The data you read
Operation pages show how sensitive their data is:
| Label | Examples |
|---|---|
| Account data | Campaign names and counts, webhook endpoints, reports. |
| Personal data | Leads, call records, phone numbers, appointments. |
| Sensitive personal data | Recordings, transcripts and AI summaries of calls. |
Protect what you store to the same standard as DialerBee does, and delete it when you no longer need
it. calls:read, recordings:read and transcripts:read cover every call of the account.
Webhook receivers
- Verify every delivery's signature over the raw body, and refuse old timestamps. See Webhooks.
- Keep your receiver's URL private and on
https://.
Actions that reach people
Tier-2 operations can start calls, schedule callbacks, send texts through appointment confirmations and make numbers callable again. They are off until DialerBee turns them on for your account, have daily caps, and are audited as they happen.
Reporting a security issue
Contact DialerBee support. Do not include a key or personal data in the report.