English
Wiring an Egypt (+20) SMS verification flow into the OTP Route API
Yes, you can receive Egyptian (+20) verification codes with OTP Route: the OTP Gateway issues a one-time +20 number for the service you choose, and the code reaches you in the dashboard, through API polling, or as a signed webhook. Prices start at $0.20 per code and are returned live for each service, and your wallet is charged only when a code lands inside the 20-minute window.
Which requests does an Egypt OTP API integration actually need?
Seven endpoints cover everything, all under https://otproute.com/api/v1 and all authenticated with a Bearer key prefixed or_live_. Generate one key per environment in the Developer console; an account can hold up to 10.
- Load the catalog with
GET /api/v1/servicesandGET /api/v1/countries. Egypt's country id iseg, and it rarely changes, so caching it is fine. - Before every order, ask
GET /api/v1/prices?country=eg&service=<id>for the current price and availability. Inventory moves during the day, so treat this response as fresh data, not configuration. - Create the activation with
POST /api/v1/activationsand a body like{"service": "whatsapp", "country": "eg"}. You get back an activation id and the +20 number to type into the screen under test. - Pick up the code from a webhook or by calling
GET /api/v1/activations/{id}. - If a test aborts, release the order with
POST /api/v1/activations/{id}/cancelso the funds return straight away.
A quick GET /api/v1/balance at the top of each suite lets a CI job stop early instead of failing halfway. The limit is 300 requests per minute per account, which leaves room for polling several activations in parallel. Full request examples sit in the developer docs.
How do I consume +20 codes from a signed webhook instead of polling?
Polling works for a single local test; a webhook is the better fit once a pipeline runs many Egyptian activations at once. Add an endpoint in the Developer console (five per account) and subscribe to activation.sms_received, plus activation.expired and activation.cancelled so your job learns when to stop waiting.
Every request carries X-OTPRoute-Signature: t=<unix>,v1=<hex>. Rebuild the string <t>.<raw body>, compute HMAC-SHA256 with the endpoint secret, and compare it to v1 with a constant-time check. Reject anything whose timestamp is stale, and hash the bytes exactly as received rather than a parsed and re-encoded object.
Treat the activation id as the idempotency key: store the event once, ignore repeats, and return a 2xx quickly. The webhook-based OTP capture guide walks through a queue-backed version of this handler.
What services can deliver codes to an Egypt verification number?
The live snapshot for Egypt lists more than 1,600 services in total. Popular ones that teams test on +20 numbers include WhatsApp, Facebook, Instagram, TikTok, Telegram, Google (Gmail & YouTube), Microsoft & Outlook, Uber, Snapchat, Viber, imo, ChatGPT (OpenAI), Amazon and LinkedIn.
That list is a point-in-time view, not a promise. A service that has numbers this morning may be thin this afternoon, which is exactly why the prices endpoint reports availability alongside the cost. Some services also turn away virtual numbers altogether; when that happens, the refund rule described below covers you.
How should an app store and validate Egyptian mobile numbers?
Egypt uses country code +20 and a domestic trunk prefix of 0. Locally a mobile number is written with eleven digits starting 01, while in international form the zero disappears and ten digits follow +20. A few habits avoid most bugs:
- Save E.164 only, such as
+201XXXXXXXXX, and format for display at render time. - Strip the trunk zero when a user enters
01…with the country already set to Egypt; otherwise you end up with an invalid+2001…value. - Normalize digits. People on Arabic keyboards may type Arabic-Indic numerals, so convert them to ASCII digits before validation and before comparing an entered OTP.
Arabic is the official language, so many services send Egyptian users their codes in Arabic, while others default to English. If your parser pulls the code out with a regex, test it against right-to-left message bodies as well as English ones.
Can the operations team order an Egyptian number without writing code?
Yes. Not every check needs a script, and support or growth colleagues can use the same OTP Gateway from the browser:
- Sign up with your email and the 6-digit code, or with Google.
- Top up the wallet and open the OTP Gateway.
- Choose Egypt and the service; the price shows before you confirm.
- Copy the +20 number into the app and wait for the code to appear on screen.
The activation is identical to an API order, so a manual check and an automated one behave the same way.
What if the +20 code never shows up?
Each activation stays open for 20 minutes. If no SMS arrives in that time, or you cancel first, the full amount goes back to your wallet automatically, so a silent number never costs you anything.
When codes keep failing:
- Let the window run its course before deciding it failed; delivery time depends on the service and the route.
- Confirm the service accepts virtual numbers at all. Some decline them, and no routing choice changes that.
- Try again a little later, or with a neighbouring route if your test does not depend on an Egyptian number.
- Avoid re-ordering in a tight loop. Leave a growing gap between orders and keep each activation id in your logs.
Our notes on reducing failed OTP deliveries go deeper on retry policy.
Why do product teams test against Egyptian numbers?
Egypt is one of the largest Arabic-speaking markets, so it is a natural first stop for teams localizing a product into Arabic. A real +20 number exercises the parts that emulators skip: the country picker, the trunk-zero handling, Arabic SMS templates and right-to-left layout on the code-entry screen.
Regional operations teams also use OTP routing to confirm that a sign-up flow still works for Egyptian customers after a release, and companies serving Egyptians living abroad check that a +20 number is accepted outside the country, too.
Is there a long-term Egyptian line, and how does billing work?
There is no self-serve long-term number for Egypt. Dedicated lines are a United States and Canada product only, from $1.95/month; if you need an ongoing Egyptian line, email [email protected] and the team can tell you whether one is possible under local rules, with no promise that it is.
Billing is a prepaid USD wallet with no monthly fee and no plan to pick. Funds go in by card or as USDT/USDC, and each top-up is followed by an emailed PDF invoice. While building the integration you can ask for sandbox mode on a development account, which returns simulated numbers and codes without touching wallet funds. Current rates are on the pricing page.
Frequently asked questions
Can I check my app's Egyptian sign-up OTP without an Egyptian SIM card?
Yes. Order a +20 number from the OTP Gateway, enter it in your sign-up form, and read the code in the dashboard or from the API, all without a local SIM.
Which country id does the OTP Route API use for Egypt?
Egypt is eg. Pass it to the prices endpoint and in the body of POST /api/v1/activations.
Do I pay for a +20 number if the SMS never arrives?
No. If no code arrives within 20 minutes, or you cancel the activation, the full amount is returned to your wallet automatically.
Should I keep the leading zero when saving an Egyptian mobile number?
No. The 0 is a domestic trunk prefix; drop it and store the number in E.164 form starting with +20.
Can I log in again next month with the same Egyptian test number?
Not reliably. Each OTP Gateway number serves one verification code, and self-serve dedicated lines exist only for the US and Canada, so plan accounts that need repeat logins around that.
Can I use Egyptian numbers to open lots of accounts on a platform?
No. OTP Route is for testing and running your own legitimate accounts and products; follow each service's terms and the Acceptable Use Policy.
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.