SimSmsBox An API Key is the most convenient way to authenticate a server-side integration, but “convenient” also means “very damaging once leaked”. This post covers how to use keys safely.
1. Never put a key in the frontend or the repo
The most common incident is committing psk_xxx into Git or bundling it into frontend JS. Remember:
- The frontend should never call the SMS API directly — relay through your own backend instead.
- The repo should only contain
.env.example; the real key goes in.envand is added to.gitignore.
# .env (not committed)
SMSHUB_API_KEY=psk_realkey_xxx
# .gitignore
.env2. One key per purpose
Don’t share a single key across the whole company. Split by service / environment:
| Key name | Purpose |
|---|---|
server-prod | Production backend |
server-staging | Staging environment |
job-bulk | Dedicated to bulk jobs |
That way, if one key has a problem, you can revoke it alone without affecting other workloads.
3. Rotate regularly
Set a rotation cycle for keys (e.g. every 90 days). Rotate with a smooth “dual-key parallel” switch:
- Create a new key;
- Gradually shift traffic to the new key;
- Revoke the old key after confirming it has no traffic.
# Create a new key
curl -X POST https://api.simsmsbox.com/api/sms/api-keys \
-H "Authorization: Bearer <token>" \
-d '{"name":"server-prod-2026q3"}'4. Three steps for a leak response
If you suspect a leak:
- Revoke the key immediately;
- Check wallet transactions for any abnormal spend;
- Create a new key and trace the leak source (logs, screenshots, third-party services).
Tip: the SimSmsBox dashboard shows the recent call records for each key, making it easy to pinpoint the source of an anomaly.
Summary
Security isn’t a single switch but a set of habits: least privilege, purpose isolation, regular rotation, controllable response. Get these four right and your SMS integration is both worry-free and safe.
Further reading: Get started with the SimSmsBox API in 5 minutes.