Passer au contenu principal
Les noms depuis lesquels vos messages peuvent être envoyés, et le moyen d’en demander un autre sans ouvrir le portail.
Demander est tout ce que cela fait. Tout ce que vous écrivez ici est stocké en attente d’approbation et n’est pas utilisable. Votre fournisseur ne sert que ce qu’il a approuvé, donc rien de ce que vous envoyez à ces endpoints ne change ce que la passerelle accepte tant que quelqu’un n’a pas décidé.C’est la partie la plus souvent mal lue : un sender ID que vous venez de créer et que vous voyez dans la liste sera quand même refusé à la soumission.

Les quatre appels

Disponibles à partir de la passerelle 0.9.7. Contre toute version plus ancienne ils ne sont pas routés et répondent 404.

Ce qu’un listing vous dit

Les quatre états

APPROVED est le seul depuis lequel vous pouvez envoyer. En particulier WITHDRAWN n’est pas une forme atténuée d’approuvé — un message envoyé depuis lui est refusé exactement comme un message non enregistré.Rapporté à partir de la passerelle 0.9.8. Avant cela, un enregistrement retiré rapportait APPROVED ici alors que son trafic était refusé, donc un client écrit contre la 0.9.7 devrait traiter un statut inconnu comme non utilisable plutôt que de supposer trois valeurs.

enforcement est le champ à lire en premier

Sur off, une ligne PENDING ne bloque rien. Sans ce champ, une liste de lignes en attente d’approbation se lit comme une file de travail bloqué, alors qu’en fait rien sur le compte n’est vérifié. Il est rapporté pour le compte et le produit du login appelant, pas pour la passerelle dans son ensemble.

En demander un

La réponse est la ligne stockée, qui portera "status": "PENDING".

Il n’y a pas de champ account, et c’est délibéré

Le compte et le produit viennent de vos identifiants, jamais du corps. Une requête nommant account, product ou system_id est refusée en nommant le champ, avec 400 Unknown argument: account, plutôt que de voir le champ silencieusement abandonné.L’abandonner en silence vous laisserait croire que vous avez enregistré un sender ID pour un autre compte. Un refus qui nomme le champ est la seule réponse honnête.
Un enregistrement fait de cette manière s’applique à chaque login de votre compte. En limiter un à un seul login est du ressort de votre fournisseur.

Stamps proposés

tlvs est stocké comme proposé et n’est jamais appliqué tel que vous l’avez envoyé. Là où les stamps sont exigés — le régime DLT indien étant le cas habituel — votre fournisseur décide des valeurs réellement attachées à votre trafic, et lit les vôtres comme une suggestion. C’est pourquoi le listing appelle le champ requested_tlvs plutôt que tlvs. C’est ce que vous avez demandé, pas ce qui est en vigueur.

En modifier un

PUT remplace ; il ne patche pas. Un champ que vous n’envoyez pas est effacé, pas conservé. Envoyez la ligne entière à chaque fois, y compris les champs que vous ne changez pas — le plus simple étant de lire d’abord la ligne avec GET.

Une modification peut mettre un sender ID en production hors service

Changer le sender ID lui-même ou la note d’un enregistrement approuvé le remet à PENDING, et il cesse d’être accepté jusqu’à ce que votre fournisseur l’approuve à nouveau. La décision de votre fournisseur portait sur l’ancien texte, elle ne se reporte donc pas. Parce que c’est vous qui arrêtez votre propre trafic, et qu’une API n’a pas de formulaire pour vous avertir, c’est refusé sauf si vous dites que c’est bien ce que vous voulez :
Envoyez "confirm_suspend": true pour continuer. Lisez le status de la réponse — un PENDING en retour est le seul avis que vous recevez qu’il a cessé d’être servi. Changer uniquement le label ne suspend jamais rien et n’exige aucune confirmation.

Reprendre une demande

Répond avec la liste restante, donc un seul appel rafraîchit votre vue. Seule une demande PENDING peut être retirée. Un sender ID approuvé est à votre fournisseur de le retirer — le retirer ici arrêterait du trafic en cours, depuis un endpoint dont tout le rôle est de demander une permission. Un id qui n’est pas le vôtre, n’existe pas, ou n’est plus en attente répondent tous le même 404. Ils sont délibérément indistinguables, pour qu’un id ne puisse pas être sondé afin d’apprendre quels comptes détiennent quels enregistrements.

Erreurs

Plus les erreurs partagées — voir Erreurs de l’API.
Un 409 sur POST est généralement une bonne nouvelle. « Ce sender ID est déjà approuvé pour ce compte » signifie que la chose que vous vouliez enregistrer est enregistrée. C’est répondu comme un conflit plutôt qu’un succès parce qu’une seconde ligne pour le même sender ID serait indistinguable de la première.

Voir aussi

Templates

Les mêmes quatre appels pour le libellé que vous envoyez.

Sender IDs et templates

La même chose via le portail, avec les états montrés en badges.

Choisir un sender ID

Ce qu’un sender ID peut contenir et comment les opérateurs le traitent.

TLVs personnalisés

Des stamps sur un message individuel, par opposition à un enregistrement.