Migrating from sms-activate.io: a 5-minute guide
If you've been running scripts against sms-activate.io for any length of time, you have a list of complaints. We had one too — that's why we built Eveses.
This isn't a marketing piece. It's a practical guide: how to move your production code from sms-activate.io to Eveses in about five minutes, with zero application changes. The compatibility layer is real, the migration cost is honest, and the risk is low because you can keep both providers running in parallel until you're satisfied.
TL;DR
- Sign up at eveses.com
- Get an API key from Account → API keys → Create
- Change your
BASE_URLfromhttps://api.sms-activate.iotohttps://api.eveses.com - Change your
API_KEYto your new key - Deploy
That's it. The same ?api_key=…&action=… query protocol works unchanged.
What "compatible" means
Eveses exposes an sms-activate-compatible gateway at the exact legacy path:
https://api.eveses.com/stubs/handler_api.php?api_key=<key>&action=getNumber&service=tg&country=0(An alias, https://api.eveses.com/api/gateway/sms-activate, is available too.)
It speaks the same protocol you already integrated: the same query parameters, the
same bare-text and JSON responses — ACCESS_NUMBER:<id>:<phone>,
STATUS_OK:<code>, ACCESS_BALANCE:42.50, and so on. Your
getNumber → getStatus → setStatus loop keeps working as-is.
The 5-minute migration, step by step
Here's a typical before/after. The only change is the base URL and the key:
# before
- curl "https://api.sms-activate.io/stubs/handler_api.php?api_key=OLD&action=getNumber&service=tg&country=0"
# after
+ curl "https://api.eveses.com/stubs/handler_api.php?api_key=NEW&action=getNumber&service=tg&country=0"Run your existing test suite against the new base URL. Because you can keep the old provider configured, you can roll out gradually — send 5% of traffic to Eveses, watch your delivery rate, then ramp to 100%.
Action reference
| action | params | returns |
|---|---|---|
getBalance | — | ACCESS_BALANCE:42.50 |
getNumbersStatus | country | {"tg_0":12,"wa_0":3} |
getPrices | country?, service? | {"0":{"tg":{"cost":0.50,"count":7}}} |
getCountries | — | country dictionary |
getOperators | — | {"0":["any"]} |
getNumber / getNumberV2 | service, country?, maxPrice? | ACCESS_NUMBER:12345:79991234567 |
getStatus | id | STATUS_WAIT_CODE · STATUS_OK:<code> · STATUS_CANCEL |
setStatus | id, status (1=ready, 3=retry, 6=finalize, 8=cancel) | ACCESS_ACTIVATION |
getActiveActivations | — | JSON list of your live activations |
Rent and multi-service actions (getRentNumber, getMultiServiceNumber, …)
aren't routed by the gateway yet and return BAD_ACTION for now.
The good part: what you gain
The gateway is the on-ramp, not the destination. Once you're on Eveses you can adopt the modern surface at your own pace:
- Typed SDKs for JavaScript, Python, Go and PHP — one install, the whole API.
- Webhooks instead of polling — get the OTP pushed the moment it lands.
- Idempotency keys so a retried buy never double-charges.
- Automatic refunds when a number never receives its code.
- An MCP server so Claude, Cursor or any AI agent can buy numbers and read codes natively.
The native path — POST /api/v1/numbers/orders/batch + a webhook — is a
short hop when you're ready. See the API reference.
The honest part: what's different
Country IDs and service codes follow the sms-activate convention on the gateway, so your existing mappings carry over. Pricing is comparable and starts around $0.05 per OTP; because Eveses refunds misses automatically, your effective cost per delivered code is often lower. Top up the wallet with crypto (via Heleket) or card — no KYC.
Run both in parallel
You don't have to cut over all at once. Keep sms-activate.io configured as a fallback, route a slice of traffic to Eveses, and compare delivery rates on real volume before you commit. When you're happy, flip the default.
Ready?
Create an account, grab an API key, and change two lines. Full side-by-side comparison: Eveses vs SMS-Activate.