Prevent Unauthorized SMS API Use

If the SMS send API is called without authorization, or an API Key is leaked and reused, large volumes of messages can go out, account balance is consumed quickly, and channel reputation can drop. EngageLab SMS can limit sending frequency, volume, and country / region scope, but it cannot replace how you protect secrets and your own send entry points.

This article explains how to combine platform capabilities with application-side protections to reduce unauthorized API use.

Correct architecture

The EngageLab SMS API must be called only from your business system server. Do not call it directly from a browser, mobile app, or mini program.

Business system server → EngageLab SMS API (with API Key; pass end_user_ip for page-triggered sends)

              
              Business system server → EngageLab SMS API (with API Key; pass end_user_ip for page-triggered sends)

This code block in the floating window

Store dev_key and dev_secret only on the server. Do not put them in frontend code, app packages, public repositories, or plaintext CI variables.
Do not expose the SMS API URL or secrets on an endpoint that end users can call directly.
For production API Keys, configure a caller IP whitelist. See API Key.

Do not mix the two types of IP

Setting / parameter	What to enter	What it blocks
API Key IP whitelist	Your server egress IP	Unknown IPs calling the SMS API with a leaked Key
`end_user_ip` in the send request	The end user's IP	The same user IP triggering sends repeatedly in a short time

After you enable "By IP address" limits in Security Center, you must pass end_user_ip in the Send SMS request for the limit to take effect. Pass the user's public IP, not your server IP. For server-side bulk marketing or notification sends without an end-user IP, IP-based rate limiting will not apply to that request. Rely more on the API Key whitelist and send volume quotas.

Platform-side protections

Complete the following configuration in the SMS console to limit damage if the API is misused:

What to do	Where	Purpose
Set an IP whitelist and expiry for the API Key, and keep it easy to disable	API Key	Restrict who can call the API; disable it immediately if leaked
Enable sending frequency limits for the same number and same IP	Security Center	Block repeated sends to one number or from one IP
Pass `end_user_ip` on page-triggered send requests	Send SMS	Make IP-based rate limiting take effect
Set daily / monthly warning and quota values	Security Center	Alert or auto-pause when volume is abnormal
Set a country / region whitelist or blacklist	Security Center	Avoid sending to countries outside your business
Pause the SMS channel in an emergency	Security Center	Stop loss quickly while misuse is happening
Configure low-balance alerts	Alert Settings	Discover unusual spend earlier

To receive notifications when a warning or quota is reached, first configure the callback event in Webhook.

Strengthen protection by template type

Different template types are abused in different ways, so the focus of protection differs.

Notification / marketing templates

These messages are usually sent in bulk from the server based on business events or campaigns. The main risk is a leaked key being used for mass sending.

Production environments must use an API Key IP whitelist.
Set reasonable daily / monthly send quotas for the app so the balance cannot be drained in one burst.
Trigger scheduled or bulk jobs only in a controlled server environment. Do not expose sending as an unauthenticated HTTP endpoint.

Verification code templates

If you use a verification code template and sending is triggered by a "Get SMS" button on a website or app, also protect your own business API:

Run a CAPTCHA (such as an image CAPTCHA, Turnstile, or reCAPTCHA) before sending, and verify the result on the server.
Set a resend interval for the same phone number (for example 60 seconds) and show a countdown on the frontend.
Limit requests per account, device, and IP by minute, hour, and calendar day. Count failed requests as well.
"Get SMS" must include a signed-in session, or a valid session in unsigned-in flows. Do not expose a public send endpoint with no context.

Treat error codes as anomaly signals

Send SMS may return the following frequency-related errors during validation or sending. When you see them, slow down retries and check for unauthorized calls or concentrated traffic:

Error code	Meaning
`3004`	Frequency limit exceeded; the same template and same recipient cannot be sent again within the limit window
`10006`	Frequency limit exceeded

If send volume has already reached the Security Center quota, or you have used Emergency Stop, later requests are rejected. Confirm the current status in Security Center first. Do not retry immediately in a tight loop.

What to do if a secret is leaked

In the SMS console, disable or rotate the API Key.
In Security Center, use Emergency Stop to pause SMS sending.
Review abnormal sends in Message Details and callbacks.
Check Alert Settings for a balance alert and review recent spend.
Tighten the API Key IP whitelist and check whether daily / monthly quotas are reasonable.
Resume sending only after the risk is gone.

Launch checklist

The API is called only from the server. dev_secret is not in the frontend, app, a public repository, or plaintext CI variables.
The production API Key has a server egress IP whitelist.
Security Center number frequency limits are on; page-triggered sends include end_user_ip.
Daily / monthly send quotas are set, and volume-related callbacks and balance alerts are configured.
Verification-code sends run CAPTCHA and business rate limits before calling EngageLab.
You know the misuse response order: disable the Key → Emergency Stop → review send records.