Skip to main content
Il vous faut trois choses de la part de celui qui exploite votre passerelle : une URL de base, un login HTTP et un mot de passe. Si votre login a été créé pour SMPP, il ne fonctionnera pas ici. C’est une séparation délibérée, pas un bug.

Envoyer un message

Un succès renvoie l’id que vous reverrez sur chaque accusé :
Mettez le destinataire entre guillemets. "to": 61491570006 est un JSON valide et perd tout zéro initial avant même que le parseur ne le voie. Envoyez-le toujours sous forme de chaîne.

Vérifiez que ça marche avant de déboguer

Deux appels, dont aucun n’envoie de message ni ne coûte quoi que ce soit :
/secure/rate tarifie un message sans l’envoyer et ne compte contre aucune limite de débit. C’est le moyen le moins coûteux de confirmer qu’une destination est routable et tarifée avant d’envoyer quoi que ce soit de réel.

Les trois choses qui refusent un premier message

Dans l’ordre où vous êtes susceptible de les rencontrer :
1

403 Authentication failure

Mot de passe incorrect, login inconnu, ou un login SMPP, qui ne peut pas du tout utiliser cette API. Le message est identique dans les trois cas.
2

403 not an approved sender ID

Votre compte a l’approbation de sender ID activée et le from envoyé n’est pas sur la liste. Omettre from utilise votre nom de login, qui n’est habituellement pas approuvé non plus.
3

402 Insufficient credit

Prépayé, et le solde ne couvre pas l’envoi. Rien n’a été envoyé et rien n’a été débité.

Et ensuite ?

Un 200 signifie accepté pour routage, pas livré. La réponse de soumission est envoyée avant l’exécution du routage. Pour savoir ce qui s’est réellement passé, demandez un accusé :

Accusés de livraison

La charge utile, les niveaux, et comment corréler sur messageId.

Chaque champ

Valeurs par défaut, refus et paramètres avancés.