Overview
SMS to Egypt fails most often for three reasons: an unregistered sender ID, wrong number formatting, or Arabic text sent with the wrong encoding. Egypt's regulator, the NTRA, requires A2P sender IDs to be pre-registered through a licensed local route — unregistered senders are blocked or have their sender ID overwritten. Register the sender ID, send numbers as 20XXXXXXXXXX with no + or 00, and use type=4 for Arabic.
Sender ID not registered (the usual cause)
Egypt only delivers A2P traffic on licensed, NTRA-approved routes, and every alphanumeric sender ID must be pre-registered. Submit with an unregistered sender ID and the gateway returns HTTP06 (Invalid Sender ID), or the message is accepted but blocked/overwritten downstream so it never arrives as your brand. Register the sender ID with BroadNet before sending, and pass it in the sid parameter exactly as approved. The parameter names (sid, mno, type) and HTTPxx error codes on this page are those of the legacy HTTP API (/websmpp); on the Bearer REST API (POST /sms/sendSms) the equivalents are senderId, destinationNumber and messageType (UNICODE for Arabic).
- Egyptian A2P runs on NTRA-licensed routes only.
- Unregistered sender ID → HTTP06 or a silent downstream block.
- Register the sender ID first; set sid to the approved value.
- Check the returned code — HTTP06 points straight at the sender ID.
Wrong number format
Destination numbers in mno must be full international format, digits only: country code 20 for Egypt followed by the national number, with no leading +, no 00, and no leading 0 on the national part. A malformed or unroutable number is rejected with HTTP09 (Invalid Destination Address). Normalise before you submit.
- Format: 20 + national number, digits only (e.g. 201001234567).
- Strip +, 00, spaces, and the national leading 0.
- Malformed numbers return HTTP09 (Invalid Destination Address).
- GET accepts up to 100 recipients, POST up to 10,000.
Arabic sent with the wrong encoding
Arabic must be sent with the correct type. Use type=4 for Arabic (up to 70 characters per segment) or type=2 for general Unicode/UCS-2; sending Arabic as type=1 (English GSM-7) mangles the text into question marks or garbage. Send the body UTF-8 encoded and URL-encoded, and remember UCS-2/Arabic segments are 70 characters, so longer messages split into more (billable) parts.
- Arabic: type=4 (70 chars/segment); general Unicode: type=2.
- type=1 (GSM-7) will corrupt Arabic text.
- Send UTF-8 and URL-encoded.
- 70-char segments — long Arabic messages cost more parts.
Confirm with the delivery report
A message accepted at submit can still fail on the network. Configure your DLR webhook (or, on the legacy HTTP API, pull status from /websmpp/websmsstatus) and read the Status: DELIVRD means it reached the handset, UNDELIV means it did not. Match reports by MessageId or BatchId, and check HTTP18 (insufficient credits) if a whole batch stalls.
- Accepted ≠ delivered — always check the DLR.
- Status DELIVRD vs UNDELIV; match on MessageId / BatchId.
- Pull status on demand (legacy HTTP API: /websmpp/websmsstatus).
- A stalled batch can be HTTP18 — insufficient credits.