Overview
L'envoi de SMS vers l'Égypte échoue le plus souvent pour trois raisons : un identifiant d'expéditeur non enregistré, un format de numéro incorrect ou un encodage incorrect du texte arabe. L'autorité égyptienne de régulation des télécommunications, la NTRA, exige que les identifiants d'expéditeur A2P soient pré-enregistrés via un réseau local agréé ; les expéditeurs non enregistrés sont bloqués ou voient leur identifiant d'expéditeur remplacé. Enregistrez votre identifiant d'expéditeur, envoyez les numéros au format 20XXXXXXXXXX sans + ni 00, et utilisez type=4 pour l'arabe.
L'identifiant de l'expéditeur n'est pas enregistré (cause habituelle).
L'Égypte n'autorise le trafic A2P que sur des routes sous licence et approuvées par la NTRA, et chaque identifiant d'expéditeur alphanumérique doit être pré-enregistré. Si vous utilisez un identifiant d'expéditeur non enregistré, la passerelle renverra l'erreur HTTP 06 (Identifiant d'expéditeur invalide), ou bien le message sera accepté mais bloqué/écrasé en aval, de sorte qu'il n'arrivera jamais sous votre marque. Enregistrez l'identifiant d'expéditeur auprès de BroadNet avant l'envoi et transmettez-le dans le paramètre sid exactement comme approuvé. Les noms de paramètres (sid, mno, type) et les codes d'erreur HTTPxx de cette page sont ceux de l'API HTTP historique (/websmpp) ; sur l'API REST avec jeton Bearer (POST /sms/sendSms), les équivalents sont senderId, destinationNumber et messageType (UNICODE pour l'arabe).
- Egyptian A2P circule uniquement sur les lignes sous licence NTRA.
- ID d'expéditeur non enregistré → HTTP06 ou blocage silencieux en aval.
- Enregistrez d'abord l'identifiant de l'expéditeur ; définissez sid sur la valeur approuvée.
- Vérifiez le code de retour : HTTP06 pointe directement vers l’identifiant de l’expéditeur.
Format de numéro incorrect
Les numéros de destination dans mno doivent être au format international complet, composés uniquement de chiffres : l’indicatif pays 20 pour l’Égypte, suivi du numéro national, sans +, 00 ni 0 initial. Un numéro mal formé ou non routable est rejeté avec l’erreur HTTP09 (Adresse de destination invalide). Veuillez le corriger avant de soumettre votre demande.
- Format : 20 + numéro national, chiffres uniquement (ex. 201001234567).
- Bande +, 00, espaces, et le 0 national en tête.
- Les numéros mal formés renvoient le code HTTP09 (Adresse de destination invalide).
- GET accepte jusqu'à 100 destinataires, POST jusqu'à 10 000.
Message arabe envoyé avec un encodage incorrect
L'arabe doit être envoyé avec le type approprié. Utilisez `type=4` pour l'arabe (jusqu'à 70 caractères par segment) ou `type=2` pour l'Unicode/UCS-2 standard. L'envoi de l'arabe avec `type=1` (GSM-7 anglais) entraîne une altération du texte, qui peut alors contenir des points d'interrogation ou des caractères illisibles. Envoyez le corps du message encodé en UTF-8 et en URL. N'oubliez pas que les segments UCS-2/arabe font 70 caractères ; les messages plus longs seront donc divisés en plusieurs parties (facturables).
- Arabe : type=4 (70 caractères/segment) ; Unicode général : type=2.
- type=1 (GSM-7) corrompra le texte arabe.
- Envoyer au format UTF-8 et encodé en URL.
- Segments de 70 caractères — les longs messages arabes nécessitent plus de segments.
Confirmer avec le rapport de livraison
Un message accepté lors de l'envoi peut néanmoins échouer sur le réseau. Configurez votre webhook DLR (ou, sur l'API HTTP historique, récupérez l'état via /websmpp/websmsstatus) et consultez le statut : DELIVRD signifie que le message a atteint le terminal, UNDELIV signifie qu'il ne l'a pas atteint. Associez les rapports par MessageId ou BatchId et vérifiez l'erreur HTTP18 (crédits insuffisants) si un lot entier est bloqué.
- Accepté ≠ livré — vérifiez toujours le DLR.
- Statut LIVRD vs UNDELIV ; correspondance sur MessageId / BatchId.
- Récupérer l'état à la demande (API HTTP historique : /websmpp/websmsstatus).
- Un lot bloqué peut être dû à HTTP18 — crédits insuffisants.