How to keep API keys safe when your website and CRM connect to a calling service
Sado AI team · · 5 min read
In short
An API key is the password your system uses to talk to a calling service. The main rules: create a separate key for each system, give it only the scopes it needs, and keep it in your server settings, never in website code, a Telegram chat or an Excel file. Replace keys when a developer or agency leaves. Check the signature on every webhook. If a key leaks, issue a new one, revoke the old one and review the leads and calls from that period.
What an API key is and why it equals a password
When your website form, CRM or 1C sends data to a calling service, it presents a key. Anyone who has the key can send leads in your name, and the voice operator will call those leads from your number. A key allowed to read transcripts opens everything your customers said.
So a leak isn’t just technical: calls go to strangers, customer data is exposed, and awkward calls happen under your brand.
Seven rules for storing API keys
- One key per system. The website form, the CRM and 1C each get their own key. If one leaks, you replace only that one.
- Only the scopes it needs. A website form only sends leads, so permission to write leads is enough. Only a system that really uses transcripts should be able to read them.
- Keys live on the server. Keep them in environment variables or a secrets store. Never put a key in code that runs in the browser or in a mobile app: anyone can read it there.
- Not in chats or files. Don’t send keys over Telegram or email, paste them into Excel or commit them to Git. If a developer needs access, create a separate key for them.
- Keep a register: which key is where, who installed it and when. For example: “website form, 3 November, developer Anvar”.
- When someone leaves, keys change. On the day a developer, agency or IT person leaves, replace every key they saw.
- Rotate even without a reason: for example, every six months.
Which system needs which scopes
| System | What it does | Scopes |
|---|---|---|
| Website form | Sends a new enquiry to be called | leads:write |
| CRM | Sends leads and reads their status | leads:write, leads:read |
| Reporting sheet | Number of calls and outcomes | calls:read |
| Quality control | Summary and conversation text | calls:content |
| Online store | Updates prices and stock | catalog:write |
The scope names come from Sado’s API. Other services name them differently, but the rule is the same: each system gets only what its job needs.
Webhooks: did the request really come from the service?
A webhook is the service sending a call’s result to your address by itself. Others may find that address, so check every request:
- Use an HTTPS address only.
- Check the signature. Sado signs every request: the X-Sado-Signature header is an HMAC-SHA256 made with your secret. If it doesn’t match, reject the request.
- Reject requests older than five minutes, so an old request can’t be replayed to fool your system.
- Keep the webhook secret on the server too.
If a key leaks: five steps
- Issue a new key and put it into the system.
- Revoke the old key at once: now, not tomorrow.
- Review the leads and calls since the leak: unknown numbers, odd times, repeated names.
- If calls are going out to fake leads, stop all calls with one button and switch them back on after the review.
- Find where the key leaked from (a chat, a file, site code), remove it there and tell the Sado team.
How API keys work in Sado
You create a key in the portal: Settings → API keys. It is shown only once, so copy it straight into your server settings. Each key has its own scopes: leads:write, leads:read, calls:read, calls:content (summary and transcript), catalog:write. One key can make 600 requests a minute. If 429 errors suddenly pile up, check: it may be a bug on your side or someone else using the key.
Every lead sent by API carries a consent basis: the person enquired, gave consent or is already your customer. As soon as a lead arrives, the AI operator calls it, and the result comes back by webhook or the event feed. Code samples are on the developers page, CRM set-up is in calls and your CRM, and short answers are in the FAQ.
Questions
Is it risky to give an API key to an outside developer?
Not much, if you create a separate key for them: when the work ends or they leave, you revoke only that key. Never hand over the keys of your other systems.
Can I put the API key in my website code?
Not in code that runs in the browser: anyone can open the page source. Let the form send data to your own server, and let the server add the key.
How often should I change an API key?
At once if someone with access leaves or you suspect a leak. Otherwise, for example, every six months.