Receiving Indian (+91) verification codes through an API

What does the India OTP API call sequence look like?

The whole flow is a handful of requests against https://otproute.com/api/v1, authenticated with a Bearer key that starts with or_live_. Keys come from the Developer console, up to 10 per account, so each environment can have its own.

1. Call GET /api/v1/countries once and cache it. India's country id is in.
2. Call GET /api/v1/prices?country=in&service=<id> for the service under test. It returns the live price and availability, so read it on every run.
3. Order with POST /api/v1/activations and a JSON body such as {"service": "telegram", "country": "in"}. The response gives you an activation id and a +91 number.
4. Enter that number on your own app's sign-up or login screen.
5. Collect the code by webhook or by polling GET /api/v1/activations/{id}. If the test dies early, call POST /api/v1/activations/{id}/cancel.

Check GET /api/v1/balance at the start of a suite so a run fails fast. The API allows 300 requests per minute, ample for polling every few seconds. Request and response details are in the API docs.

How should a webhook handler for +91 codes be built?

A signed webhook scales better than polling once jobs run in parallel. Register an endpoint in the Developer console (up to 5 per account) and listen for activation.sms_received, activation.expired and activation.cancelled.

Each delivery carries an X-OTPRoute-Signature header shaped like t=<unix>,v1=<hex>. To check it, compute HMAC-SHA256 over the string <t>.<raw body> with that endpoint's secret and compare the result with v1 in constant time. Two details catch people out:

• Hash the raw request bytes, never a re-serialized JSON object; key order and whitespace change the digest.
• Refuse timestamps older than a few minutes so a captured request cannot be replayed.

Key your writes on the activation id so a duplicate delivery becomes a no-op, and acknowledge with a 2xx before doing slow work. Our write-up on securing OTP webhooks with HMAC covers the comparison step line by line.

Which services can send codes to Indian numbers?

The India route currently lists more than 2,300 services. Popular entries in the live snapshot include WhatsApp, Telegram, Google (Gmail & YouTube), Instagram, Facebook, X (Twitter), ChatGPT (OpenAI), Microsoft & Outlook, Amazon, LinkedIn, Discord, Uber and Snapchat.

Availability shifts through the day, which is why the API reports it live. If your test matrix depends on one service, query prices for in before the run and skip cleanly when that route is closed. Use these routes only for your own products and accounts, follow each service's terms, and keep in mind that OTP Route's Acceptable Use Policy applies.

Can non-developers order an India verification number from the dashboard?

Yes. Ops staff and agency account managers can skip the API:

1. Create an account with your email and a 6-digit email code, or with Google sign-in, then switch on TOTP two-factor.
2. Top up the wallet.
3. Pick India and the service, check the price on screen, and place the order.
4. Type the +91 number into the app you are setting up; the code appears on the activation page once the SMS lands.

The dashboard and the API share one window, one refund rule and one wallet.

What should I do when no code arrives within 20 minutes?

Every activation stays open for 20 minutes. You pay only if the SMS arrives: when the window closes empty, or you cancel first, the full amount returns to your wallet automatically and your webhook receives activation.expired or activation.cancelled.

If a code is missing:

• Let the window run before reacting; a service can simply be slower than usual to send.
• Confirm the service accepts virtual numbers at all. Some platforms decline them, which is a policy on their side rather than a delivery fault.
• Try again later, or test with a different service route.
• Never re-order in a tight loop. Back off between attempts so you are not spending effort on a route that is refusing numbers.

There is a longer treatment of retry strategy in reducing failed OTP deliveries.

How should Indian phone numbers be stored and normalized?

Indian mobile numbers are ten digits long and in practice begin with 6, 7, 8 or 9. People inside India often write them with a leading trunk 0, or split them five and five with a space. International format drops that 0 and adds the country code, giving +91 followed by the ten digits.

Store only the E.164 form: +91 plus ten digits, with no spaces, hyphens or zero. Normalize input at the edge by stripping formatting, a leading 0, or a bare 91 typed without the plus. That prevents duplicate users who differ only by formatting.

Most verification SMS in India arrive in English and come from an alphanumeric sender header rather than a phone number. Some apps send Hindi or another regional language instead, so test any code parser against non-Latin scripts too.

Why do product teams need a +91 number for testing?

India is a common launch market for consumer apps, fintech onboarding and marketplaces, and its users expect an SMS step at sign-up. Teams use +91 routes to rehearse a launch, to run localization QA across Hindi, Tamil, Telugu, Bengali, Marathi and other interfaces, to support regional operations staff, and to check flows used by Indian diaspora customers abroad who still sign in with a home number. Good OTP routing here means picking the service route that matches the real user journey, then wiring it into the same SMS verification API calls your other markets use.

Is there a long-term Indian line, and how does billing work?

No. Dedicated numbers are a US and Canada product, from $1.95/month, and you cannot purchase a long-term Indian line from the dashboard. If you need one, email [email protected]; availability depends on local rules and is not guaranteed.

Billing runs on a single prepaid USD wallet with no monthly fee and no plan to choose. Top up by card or with USDT/USDC stablecoins, and every top-up arrives with a PDF invoice by email. For integration work, ask support to switch a development account to sandbox: it returns simulated numbers and codes, so you can test your webhook handler end to end without spending wallet funds.

Frequently asked questions

Can I test my app's Indian sign-up flow without a local SIM?

Yes. Order a +91 number through the OTP Gateway, enter it on your sign-up screen, and read the code from the dashboard, the API or your webhook.

What is the country id for India in the OTP Route API?

It is in. Pass it as the country in GET /api/v1/prices and in the body of POST /api/v1/activations.

How much does it cost to receive an India SMS OTP?

Codes start at $0.20 per code and the exact price depends on the service. You see it before ordering, and an activation that gets no code is refunded to your wallet.

Can I reuse the same +91 number to log in again next month?

No. A gateway number covers one verification code. Accounts that need repeat logins belong on a dedicated line, and those exist only in the US and Canada.

Is there a sandbox for building the India integration?

Yes, on request. Support can move a development account to sandbox, where simulated numbers and codes flow through your code without touching the wallet.

Can our finance team pay with stablecoins?

Yes. The wallet takes card payments as well as USDT and USDC, and each top-up produces a PDF invoice by email.

Service names are trademarks of their respective owners. OTP Route is not affiliated with them. Use numbers lawfully, follow each service's terms and our Acceptable Use Policy.