Documentation de l’API REST
Effectuez votre première requête à l’API MultiTEL
Commencez par une requête en lecture seule, comprenez la réponse, puis choisissez la référence pour le service que vous souhaitez développer.
Choisir l’API et l’identifiant ensemble
Les comptes approuvés Développeurs et automatisation, Entreprise et Fournisseur de communications peuvent intégrer les services activés. Un développeur individuel n’a pas besoin de se présenter comme une entreprise. Les SMS/MMS applicatifs exigent l’approbation d’envoi et l’inscription applicables. Le service Particuliers et famille ne dispose d’aucune API d’émission de messages accessible au client.
| Famille d’API | URL de base | Authentification et résultat |
|---|---|---|
| Communications v3 | https://api.multitel.net/v3 | Identifiants Basic approuvés ; jetons provisionnés éligibles uniquement pour les opérations qui les prennent en charge. JSON status et response. |
| Enregistrement d’urgence | https://api.multi.tel/emergency | Identifiants Basic approuvés ou accès par jeton bearer spécialement configuré. JSON code, message et data. |
| Intégrations REST du portail | Hôte et opération indiqués dans la référence développeur de votre compte | Utilisez les identifiants d’authentification, les portées et le schéma documentés pour cette opération. Les requêtes de session du navigateur sont distinctes. |
Définissez MULTITEL_API_USERNAME et MULTITEL_API_PASSWORD dans la configuration des secrets de votre serveur avant d’utiliser les exemples. Ne les intégrez jamais au JavaScript public du navigateur, aux URL ou à un dépôt de code source. Les identifiants dédiés sont gérés dans les paramètres d’intégration API.
Première demande : lire votre solde
Cette lecture n’achète aucun service et n’émet aucun appel ni message.
curl --fail-with-body \
--user "$MULTITEL_API_USERNAME:$MULTITEL_API_PASSWORD" \
--header "Accept: application/json" \
"https://api.multitel.net/v3/getbalance"L’API Communications v3 renvoie un résultat applicatif dans le corps JSON. Vérifiez le statut HTTP et status.code avant de lire response ; une demande rejetée peut ne comporter aucun objet de réponse. Les valeurs de code peuvent être des chaînes ou des nombres.
{
"status": {
"code": 200,
"msg": ""
},
"response": {
"balance": "25.0000",
"currency": "USD",
"terms": "Prepaid"
}
}Ceci est un exemple fictif, et non un solde de compte. Considérez les valeurs monétaires comme des montants décimaux. Conservez le message de réponse du serveur lors du diagnostic d’une demande rejetée, après en avoir retiré les identifiants.
Utiliser correctement les données de facturation
La réponse de solde contient le solde actuel, la devise et les conditions de paiement. Elle ne donne ni le coût d’un futur appel ni une facture complète. Utilisez les opérations correspondantes de tarifs et d’usage pour ces questions. Les numéros existants peuvent avoir des forfaits différents du catalogue actuel.
Choisissez votre prochaine intégration
API REST de recherche de routage LRN
Recherchez le numéro d’acheminement et les informations disponibles sur l’opérateur d’un numéro de téléphone nord-américain, à un tarif fixe.
Lire le guide d’intégration →API REST des numéros de téléphone
Découvrez les pays et numéros disponibles, inspectez l'offre complète et gérez les numéros que vous possédez.
Lire le guide d’intégration →API REST SMS & MMS
Envoyez des messages d'application approuvés et gérez l'acceptation, les événements de livraison, la segmentation et les frais.
Lire le guide d’intégration →API REST d'appel d'urgence
Enregistrez un numéro et une adresse de service, suivez son statut d'activation et maintenez l'enregistrement lorsque le lieu change.
Lire le guide d’intégration →API REST du compte & facturation
Lisez le solde et les informations de facturation disponibles pour votre intégration approuvée.
Lire le guide d’intégration →CNAM et recherches de routage
Lisez les noms des appelants, comprenez les niveaux de recherche et utilisez les informations de routage des numéros.
Référence CNAM REST →PBX hébergé
Commencez par les forfaits disponibles et l’environnement client que vous souhaitez configurer.
API des plans de service PBX hébergé →Gérer les erreurs et les nouvelles tentatives
- Échec d’authentification ou d’autorisation
- Vérifiez l’état d’activation de l’identifiant API, le service autorisé et la restriction d’adresse IP source. Un cookie de session du portail n’est pas un identifiant d’intégration.
- Crédit insuffisant ou approbation manquante
- Régularisez le solde du compte, obtenez l’approbation d’envoi ou fournissez les documents requis avant de répéter l’opération.
- Aucun résultat
- Considérez un inventaire vide ou un nom d’appelant manquant comme un résultat ordinaire. Ne supposez pas qu’un numéro syntaxiquement valide dispose de tous les services.
- Délai d’attente réseau ou défaillance de service
- Utilisez des nouvelles tentatives limitées avec attente progressive pour les lectures. Pour un achat, un envoi ou une inscription, vérifiez d’abord l’état de l’opération ; réessayer une demande acceptée peut dupliquer une action facturable.
La prise en charge de l’idempotence dépend de chaque famille d’API. L’API Emergency prend en charge les clés de nouvelle tentative ; cela ne rend pas idempotentes les demandes v3 arbitraires. Conservez les horodatages, les identifiants renvoyés et les réponses expurgées pour l’assistance.
Poursuivez avec la référence de votre compte
La documentation accessible après connexion affiche les opérations correspondant à vos autorisations et aux services activés. Utilisez l’hôte exact, le type d’identifiant d’authentification, les champs de requête et le schéma de réponse indiqués. Les consoles peuvent exécuter des opérations réelles, notamment des achats et des envois de messages.