Receiving X (Twitter) SMS codes: a checklist for product and QA teams

What does X ask for a phone number for?

X uses phone numbers in a handful of well-known places: as an alternative to email at sign-up, when you add a number to an existing account, during login challenges triggered by activity that looks unusual, for password reset, and for two-factor authentication by text message. X has narrowed which accounts can use SMS two-factor over the years and offers authenticator apps as an option, so check the current settings for the account you are testing. Each of these flows sends a short numeric code, and each is worth covering if your product integrates with or manages X accounts. Typical cases are a social media tool that onboards brand accounts, an agency that runs client profiles from a shared team login, and a QA suite that checks how your own app behaves after a user links an X profile.

Pre-flight checklist for X (Twitter) SMS verification testing

• Ownership. The account belongs to you, your company or a client who asked you to manage it. One account per real person or business.
• Terms. Read X's rules on phone numbers and automation; they apply on top of our Acceptable Use Policy.
• Country. Decide which market the account represents before ordering.
• Service id. On OTP Route the X service id is twitter.
• Plumbing. A Bearer key (or_live_) and either a polling loop or a webhook endpoint.
• Lifespan. Will this account need to log in again in a month? If so, read the dedicated-line section before you start.

Which of the 198 countries should the number come from?

The X route covers 198 countries, including the United States, Canada, the United Kingdom, Germany, France, India, Indonesia, the Philippines, Japan, Brazil, Mexico, Turkey, Saudi Arabia, Kenya, Nigeria and Ghana. Match the number to the market the account serves or the test case you are proving: a regional brand account should carry a number from its region, and a localisation test needs the language and number format of that country. A mismatch between number, IP location and profile is also the kind of signal that can prompt extra checks on X's side.

Steps: ordering a number for X through the API

Base URL: https://otproute.com/api/v1.

1. Look up the price for your pair with GET /api/v1/prices?country=<id>&service=twitter, which also confirms live availability.
2. Create the order: POST /api/v1/activations with {"service": "twitter", "country": "<id>"}. Save the activation id.
3. Enter the returned number in X's phone field.
4. Pick up the code from the webhook event, or poll GET /api/v1/activations/{id} until it appears.
5. If X rejects the number, release it with POST /api/v1/activations/{id}/cancel.

Country ids come from GET /api/v1/countries; the API docs show request and response shapes.

How should the webhook receiver be built?

Subscribe to activation.sms_received, activation.expired and activation.cancelled. Every delivery carries X-OTPRoute-Signature: t=<unix>,v1=<hex>; compute HMAC-SHA256 over the timestamp, a dot and the raw body with the endpoint secret, compare in constant time, and refuse old timestamps. Since deliveries can repeat, store processed activation ids and ignore duplicates. Polling is a fine fallback for small suites, well within 300 requests per minute. The HMAC guide has a worked example.

Prefer clicking? In the dashboard, open the OTP Gateway, choose X and a country, confirm the displayed price, paste the number into X, and watch the code appear beside the order.

Troubleshooting: X didn't send a code

• The number was refused. X may decline virtual numbers, sometimes with a message that the number cannot be used. Cancel, then retry later or with another country.
• Nothing arrived yet. Leave the 20-minute window open rather than ordering again immediately.
• X is throttling. Repeated requests from one account can trigger X's own limits; space out attempts.
• Your handler dropped it. Check signature failures and errors in your logs.
• The account is flagged. If X has restricted the account itself, a new number will not change that; resolve it through X's own support channels.

The refund rule removes the cost of failure: you pay only if the code arrives, and expired or cancelled activations return the full amount to the wallet.

When is a US or Canadian dedicated line the better fit?

A one-time activation suits a single verification. A company account that must pass login challenges or recover access months from now needs a number that stays put. Dedicated Numbers give you that in the United States and Canada, from $1.95/month: inbound SMS in the dashboard and on your webhook via number.sms_received, outbound SMS and browser calling. Compare both on virtual numbers. OTP Route bills everything from one prepaid wallet, topped up by card or USDT/USDC, with PDF invoices.

Frequently asked questions

What is the service id for X (Twitter) in the OTP Route API?

It is twitter. Use it in the prices request and in the activation body.

Can I receive an X OTP without a SIM card?

Yes, on an OTP Gateway number in any of 198 countries, shown in the dashboard or sent to your webhook.

Why did X say my phone number can't be used?

X may refuse some virtual numbers. Cancel the activation for a refund and try another country or a later time.

How much is an X verification code?

From $0.20 per code; the exact price depends on the country and is shown before you order.

Can I reuse the same number for X login later?

A one-time activation receives one code. For repeat logins use a US or Canadian dedicated number.

Can I use OTP Route to create many X accounts?

No. It is for testing and operating your own legitimate accounts and products under X's terms.

Is there a sandbox for building the integration?

Yes. On request a development account can switch to sandbox and return simulated numbers and codes.

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.