The SMS-Activate shutdown explained: migrating your API integration

Key points

• SMS-Activate stopped operating in late December 2025, according to third-party reports; there is no official route to recover old balances, and sites still using the name are not the original service.
• If your code called its API, you are not just swapping a URL. You are re-mapping an order lifecycle: create, wait, receive, cancel, refund, plus the error cases in between.
• Treat migration as two jobs. First move the accounts that still depend on old numbers. Then rebuild the integration against a provider whose refund and status rules you have tested.

When a verification provider disappears, two groups get hurt. People who used it by hand lose a website. Developers lose a dependency that was wired into scripts, QA pipelines and reseller back-ends. This guide is for the second group. It sums up what is publicly reported about the SMS-Activate shutdown, then walks through migrating an API integration without breaking production or losing money along the way.

If you mainly want to compare providers, our SMS-Activate alternatives guide and the SMS-Activate alternative page cover that. This article is about the engineering side.

What is actually known about the shutdown

Last reviewed: 1 October 2026. We could not find a detailed official statement from the operator that we could verify independently. Everything below comes from third-party reports, and we say which report says what.

• Timing. Non-Voip's write-up says the service halted operations on 29 December 2025. An account on sms-act.net says the operator's own page gave 22 December 2025 as the day all activity stopped, and 29 December as the day the closure was widely reported.
• It is permanent. Non-Voip's report says you can no longer buy numbers or top up accounts.
• Balances. BitBrowser's summary says remaining balances were difficult or impossible to recover. The sms-act.net account says there was a withdrawal channel, with a minimum balance requirement, that stayed open until 5 February 2026 and is now closed.
• Successor. BitBrowser reports that users were pointed to HeroSMS, and stresses that it is a separate platform, not a continuation of SMS-Activate accounts or balances. Our HeroSMS page looks at it on its own merits.
• Look-alikes. BitBrowser and sms-act.net both warn about unofficial sites using the SMS-Activate name. Don't send funds or API keys to any of them.

The reports differ a little on dates. None of them documents an API hand-off, a compatibility layer or a way to transfer order history. Assume nothing carries over.

Step 0: stop the bleeding

Before touching code, deal with the fallout that costs money or access.

1. Revoke and rotate secrets. If an old API key sits in environment files, CI variables or a password manager entry shared with a look-alike site, delete it. A dead provider's key is harmless. A key you pasted into a phishing clone is not.
2. Disable the jobs. Scheduled scripts that still call the old endpoints will fail noisily at best. At worst they fall back to some hard-coded mirror someone added during an outage. Turn them off explicitly.
3. Find accounts that still depend on old numbers. Any account verified with a rented or one-time SMS-Activate number and still using that number for login or recovery is now one reset away from lockout. Move those first: add an authenticator app or passkey, save backup codes, then change the phone number to one you control. Our guide to keeping your number for 2FA explains why this matters.

Step 1: write down the contract you actually depended on

Most verification integrations boil down to the same state machine, even when the old provider called things by different names. Before you pick a new API, list what your code expects:

• Create an order. Input: service and country. Output: an order ID and a phone number in some format.
• Wait. Either polling a status endpoint or receiving a callback.
• Receive. Get the code, the full SMS text, or both.
• Finish or cancel. Tell the provider you're done, or cancel for a refund if nothing arrived.
• Errors. No balance, no numbers available for this country/service, bad key, rate limited.

Then note the implicit behaviour your code relies on. How long an order stays open. Whether you're charged on creation or on delivery. Whether a cancel refunds immediately. Whether you can ask for a second SMS on the same number. These are the things that silently change when you switch providers, and they're where migrations go wrong.

Step 2: map old concepts to the new API

Whatever provider you move to, build a small mapping table like the one below and review it with whoever owns the billing side. This example uses the PhoneBorn OTP Verification API, because that's the one we can describe accurately.

Names differ from provider to provider. What matters is that every row has a clear answer before you ship.

Step 3: put an adapter between your code and the provider

The most useful lesson from the shutdown is architectural: never let a provider's API shape leak into your business logic. Wrap it.

A thin adapter with four methods (create_order, get_order, cancel_order, list_prices) and a normalised order object (id, number_e164, status, code, expires_at, refunded) lets you:

• swap providers without touching the callers;
• run two providers side by side during migration;
• write tests against a fake provider that simulates timeouts, 409s and late codes.

Normalise phone numbers to E.164 inside the adapter. Providers return numbers with and without the plus sign, with spaces, or split into country code and national number. Your callers should only ever see one format.

Normalise statuses too. A good minimal set is waiting, received, cancelled, expired. Map anything else explicitly. Don't let unknown strings fall through to a default.

Step 4: get the timing and refund logic right

Most money is lost here, not in the unit price.

• Respect the order window. Enter the number into the target platform as soon as the order is created. The countdown starts immediately, and a slow browser automation step can eat half of it.
• Request the SMS once. Hammering "resend" on the target platform triggers its rate limits, not the provider's. It can also get the number flagged.
• Cancel early when the platform rejects the number. If the target service refuses the number outright, cancel and retry with another country instead of waiting out the window.
• Handle late codes. Decide what happens when a code arrives after your own timeout fired but before you cancelled. With PhoneBorn, cancelling after a code has arrived returns 409, so your code should treat that as "a code is available" rather than as a failure.
• Idempotency on your side. If your worker crashes after creating an order, don't create a second one on restart. Store the order ID first, then act on it.

A simple polling loop looks like this in Python (error handling trimmed for clarity):

def get_code(service, country, timeout=300):
    order = client.create_order(service=service, country=country)
    deadline = time.time() + min(timeout, order.seconds_left)
    while time.time() < deadline:
        order = client.get_order(order.id)
        if order.status == "received":
            return order.code
        if order.status in ("cancelled", "expired"):
            return None  # already refunded
        time.sleep(4)
    client.cancel_order(order.id)  # refund if still waiting
    return None

At higher volume, switch to webhooks and verify the signature on every callback rather than trusting the payload.

Step 5: choose countries by delivery, not by habit

Integrations built on the old provider often hard-coded one or two countries that used to be cheap. Those defaults are worth revisiting. Delivery depends on the target platform's own rules and on whether the number is a real mobile number or a VoIP range. Our VoIP vs mobile checker and the which countries work for tool help you pick defaults based on evidence.

Keep a fallback list per service: if the first country returns 409 or the platform rejects the number, the adapter moves to the next one automatically.

Step 6: run both paths, then cut over

A low-risk cut-over plan:

1. Shadow mode. Keep your production path on whatever stop-gap you're using. Send a small share of test traffic through the new adapter and log outcomes: delivered, expired, rejected by platform, cancelled.
2. Compare. Look at delivery rate per service and country, median time to code, and refund rate. Unit price alone tells you little if a third of orders never deliver. It's how much you pay per delivered code that matters.
3. Ramp. Move 10%, then 50%, then 100% of traffic, with a kill switch at each step.
4. Reconcile money. Check that every cancelled or expired order was actually refunded to your balance. Do this daily for the first week.

Step 7: separate throwaway sign-ups from accounts you keep

The shutdown hurt most where one-time numbers had quietly become the login factor for accounts people cared about. Fix this in your process, not only in your code:

• Use single-use OTP numbers for test accounts and sign-ups you don't need to recover.
• Use a number you rent and renew, like a PhoneBorn phone number plan on a real mobile network, for any account that will ever need a login or recovery code again.
• For accounts you keep, add an authenticator app or passkey as well, so no single number is a single point of failure.

Responsible use

Automating verification is common and legitimate in QA, app testing and reselling. Using it for fake reviews, spam, ban evasion or fraud is not. It also breaks the target platforms' terms and PhoneBorn's acceptable use policy. Build rate limits into your own tooling, and keep logs good enough to answer an abuse report.

FAQ

Can I still get my SMS-Activate balance back?

According to sms-act.net, the only withdrawal channel closed on 5 February 2026, and no official recovery route is reported. Be very wary of any site offering to recover it for a fee.

Is HeroSMS the same service with a new name?

No. BitBrowser reports that users were pointed to HeroSMS, but describes it as a separate platform. Old accounts and balances didn't carry over. Evaluate it like any other provider.

Will my old API client work with another provider if I change the base URL?

Don't count on it. Even where request formats look similar, providers differ on when they charge, how long orders last, how cancellations refund and which error codes they return. Put an adapter in front of the provider and test each state.

What happens to accounts verified with SMS-Activate numbers?

They keep working until the platform asks for an SMS code again. Then you can't receive it. Log in now, add an authenticator app or backup codes, and change the phone number to one you control.

Can one PhoneBorn OTP order receive several codes?

No. An OTP order is single-use and receives one code. If no code arrives, the order is refunded automatically. For repeat logins or re-verification, rent a phone number plan you keep.

How do I test a new provider without risking much?

Run a few dozen orders across your top services and countries. Record delivery rate and time to code, and confirm refunds on failed orders reach your balance before you move real traffic.