Skip to main content
REST, sauf si vous avez une raison de faire autrement. Un appel HTTPS par message, rien à maintenir en vie, et tous les langages le parlent.SMPP justifie sa complexité à volume soutenu élevé, quand un bind persistant évite une poignée de main TCP et TLS par message, et quand vous voulez le protocole que les opérateurs eux-mêmes utilisent.Tout ce qui se passe en aval de l’acceptation est identique dans les deux cas : mêmes routage, tarification, approbations et accusés.
Non. Les identifiants sont typés HTTP ou SMPP, et les deux ne sont pas interchangeables. Demandez-en un de chaque si vous avez besoin des deux.C’est la cause d’un 403 Authentication failure qui survit à toute vérification du mot de passe : le login est bon, il est simplement du mauvais type pour la porte à laquelle vous frappez.
C’est la décision de votre fournisseur, pas une propriété de la passerelle. Demandez-lui.Ce qui existe partout est /secure/rate, qui tarifie un message sans l’envoyer, ne débite rien et ne compte contre aucune limite de débit. Assez pour valider destinations, encodage et prix avant d’envoyer quoi que ce soit de réel.
Non. L’API est assez petite pour qu’un client HTTP et quatre lignes de code suffisent. Voir Quickstart pour curl, Node, Python et PHP.
Vérifiez tout document OpenAPI qui vous a été fourni contre ces pages avant de générer un client. Une spécification plus ancienne circule encore, qui type custom_tlvs comme un tableau alors qu’il doit être un objet, type validity_period comme une chaîne alors qu’il doit être un entier, et omet product.
Celle de votre fournisseur, pas une valeur fixée. Chaque opérateur exploite son propre FireFlo. Tous les exemples ici utilisent https://sms.example.com comme substitut.
Oui, si vous envoyez par rafales. Votre compte a une limite messages-par-seconde. Au-dessus, vous recevez 429 avec aucun en-tête Retry-After.Faites un backoff exponentiel avec du jitter. Un intervalle de retry fixe partagé entre plusieurs workers les resynchronise sur la prochaine rafale, transformant une limite momentanée en limite prolongée.
Un accusé de livraison, et rien d’autre. Demandez-en un avec "dlr": "yes" et un dlr_url.Attendez un accusé de niveau 2. ACCEPTD et BUFFRED arrivent en niveau 1 et un autre suit. Un client qui traite le premier accusé comme final rapportera toujours le mauvais résultat.
Parce que vous avez envoyé trois submit_sm. conf.dlr.multipart vaut par défaut all, donc il y a un accusé par segment soumis, chacun citant l’id qui vous a été remis.Votre fournisseur peut le régler sur first ou last pour n’en laisser qu’un. Chaque accusé rapporte le même résultat quel que soit son choix, parce que les segments sont agrégés avant qu’un accusé ne soit construit.
Parce que le destinataire n’a pas reçu de message lisible. La résolution attend le dernier segment et rapporte le pire résultat, pas le premier.C’est la réponse honnête, et elle fait baisser les taux de livraison affichés par rapport aux passerelles qui rapportent le premier segment. À savoir avant de comparer les fournisseurs sur un taux de livraison.
Oui. Le portail client affiche vos propres messages avec recherche et export CSV, et votre relevé séparément. Voir le portail.Vous voyez les TLVs que vous avez envoyés sur vos propres messages. Ce qu’un fournisseur a ajouté en aval ne vous appartient pas et n’est pas visible.