Checklist de l'API eSIM (2026) : 12 fonctionnalités indispensables pour une API eSIM de voyage — et comment tester chacune d'elles

Connecter une API eSIM à votre application, plateforme de voyage ou moteur de réservation n'est pas difficile. Ce qui est difficile, c'est de découvrir, après le lancement, que l'API facture deux fois en cas de timeout, qu'elle ne peut pas vous dire quand un client n'a plus de données, ou qu'elle ne vous donne aucun moyen de tester les échecs.

Cette checklist couvre les 12 fonctionnalités essentielles en production, et pour chacune d'elles, comment la tester avant de vous engager. Nous utilisons l'API TripoSIM Partner comme exemple concret, mais vous pouvez utiliser la même liste pour comparer n'importe quel fournisseur.

1. Authentification par jeton sécurisée

Ce qu'il faut rechercher : Des identifiants client OAuth 2.0 : vous échangez un client ID et un secret contre un jeton d'accès à courte durée de vie. Les secrets ne voyagent jamais avec chaque requête.

Comment tester : demandez un jeton, puis vérifiez qu'il expire. Dans l'API TripoSIM, POST /auth/token renvoie un jeton d'accès valide pendant 15 minutes. Assurez-vous que votre code le rafraîchit automatiquement avant son expiration.

2. Clés d'idempotence (pas de doubles facturations)

Ce qu'il faut rechercher : un en-tête Idempotency-Key sur chaque commande et recharge. Si votre requête subit un timeout et que vous réessayez avec la même clé, l'API doit renvoyer le résultat original au lieu de créer une deuxième eSIM payante.

Comment tester : envoyez la même commande deux fois avec la même clé et confirmez que vous ne recevez qu'une seule commande. Ensuite, envoyez la même clé avec un corps de requête différent — une bonne API la rejettera. TripoSIM exige la clé pour les commandes et recharges en production et renvoie 409 IDEMPOTENCY_KEY_REUSED si une clé est réutilisée avec une requête différente.

3. Devis qui bloquent le prix

Ce qu'il faut rechercher : un moyen de récupérer un prix et de le maintenir pendant une courte période, afin que votre client paie exactement ce que vous lui avez montré.

Comment tester : créez un devis, attendez, puis commandez avec celui-ci. Les devis TripoSIM sont valides pendant 10 minutes ; un devis expiré renvoie 409 QUOTE_EXPIRED afin que vous puissiez refaire un devis au lieu de facturer un prix surprise.

4. Un flux de catalogue propre

Ce qu'il faut rechercher : un point de terminaison (endpoint) qui liste chaque forfait avec le prix, les données, la validité, les pays de couverture, la 5G, le support des recharges — et pour les forfaits illimités, la limite quotidienne à pleine vitesse.

Comment tester : récupérez le catalogue pour un pays et comparez-le avec le site web du fournisseur. L'endpoint TripoSIM /catalog renvoie du JSON ou du CSV, inclut les forfaits régionaux couvrant le pays, et ajoute les champs de fair-use (fup_daily_mb, fup_throttle_kbps) pour les forfaits illimités. Voir [comment fonctionnent les limites quotidiennes illimitées](/blog/unlimited-esim-daily-limit-by-country-2026).

5. Livraison instantanée de la commande et du QR

Ce qu'il faut rechercher : la réponse de la commande (ou un webhook quelques secondes plus tard) doit inclure le code d'activation au format LPA standard, par exemple LPA:1$smdp.example.com$ACTIVATION_CODE, afin que vous puissiez afficher un code QR ou un lien d'installation en un clic.

Comment tester : passez une commande dans le sandbox, générez le QR à partir de la chaîne LPA, et scannez-le avec l'appareil photo d'un téléphone pour vérifier que le format est valide.

6. Webhooks signés pour chaque événement

Ce qu'il faut rechercher : des notifications push pour tout le cycle de vie de l'eSIM, signées pour que les attaquants ne puissent pas les falsifier.

TripoSIM envoie huit types d'événements : order.completed, order.failed, esim.activated, esim.usage_80, esim.suspended, esim.resumed, esim.depleted et esim.expired. Chaque requête porte un en-tête X-TripoSIM-Signature — un HMAC-SHA256 de l'horodatage et du corps brut utilisant votre secret de signature :

<pre><code>// reject requests older than 5 minutes (replay protection) if (Math.floor(Date.now() / 1000) - parseInt(timestamp) &gt; 300) throw new Error('Webhook too old'); const expected = crypto .createHmac('sha256', signingSecret) .update(timestamp + '.' + rawBody) .digest('hex'); if (!crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) { throw new Error('Invalid webhook signature'); }</code></pre>

Comment tester : enregistrez un webhook, déclenchez une commande et vérifiez la signature dans votre code. Ensuite, modifiez un seul octet du corps de la requête et assurez-vous que votre vérification la rejette.

7. Un sandbox qui simule toute la vie de l'eSIM

Ce qu'il faut rechercher : les véritables eSIM prennent des jours pour s'activer et consommer des données. Un bon sandbox vous permet d'accélérer le processus.

Comment tester : dans le sandbox TripoSIM, utilisez POST /sandbox/esims/{iccid}/simulate avec une action de type activate, usage, deplete, expire ou reset. Chaque étape déclenche le webhook correspondant, ce qui vous permet de tester votre e-mail "vos données sont presque épuisées" en quelques minutes au lieu de plusieurs jours.

8. Simulation d'échecs

Ce qu'il faut rechercher : un moyen de forcer des erreurs intentionnellement, afin de savoir si votre application les gère correctement.

Comment tester : envoyez l'en-tête X-Sandbox-Simulate avec des modes comme insufficient_balance, price_changed, rate_limit, provider_unavailable ou timeout, et vérifiez que votre application affiche un message clair et ne réessaie que lorsque c'est nécessaire.

9. Recharges sur la même eSIM

Ce qu'il faut rechercher : les clients qui n'ont plus de données doivent pouvoir en ajouter sans installer une nouvelle eSIM.

Comment tester : appelez POST /esims/{iccid}/topup dans le sandbox (avec une clé d'idempotence), puis vérifiez le nouveau solde de données. Vérifiez également quels forfaits supportent les recharges — le catalogue doit vous l'indiquer.

10. Données d'utilisation et de statut

Ce qu'il faut rechercher : un endpoint pour les données utilisées, les données restantes et l'expiration, afin que votre équipe support et votre application puissent répondre à "combien de données me reste-t-il ?".

Comment tester : appelez GET /esims/{iccid}/usage après un événement d'utilisation simulé. TripoSIM met en cache l'utilisation pendant 5 minutes, utilisez donc les webhooks (esim.usage_80, esim.depleted) pour des alertes en temps réel.

11. Suspension et reprise

Ce qu'il faut rechercher : un moyen de mettre une eSIM en pause — par exemple lorsqu'un paiement est contesté ou qu'un client signale la perte de son téléphone — et de la reprendre plus tard.

Comment tester : suspendez une eSIM dans le sandbox, confirmez que le webhook esim.suspended arrive, puis reprenez-la et confirmez esim.resumed.

12. Limites de débit, codes d'erreur et changelog clairs

Ce qu'il faut rechercher : des limites documentées, des codes d'erreur qui vous indiquent s'il faut réessayer, et un changelog public pour que les mises à jour ne vous surprennent jamais.

Comment tester : lisez la liste des erreurs et associez chaque code à "réessayer" ou "ne pas réessayer" dans votre code. TripoSIM autorise 120 requêtes par minute par compte partenaire (vous pouvez définir des limites inférieures pour des clés API individuelles), renvoie un en-tête Retry-After sur les réponses 429, marque chaque code d'erreur comme réessayable ou non, et publie un endpoint de changelog.

Un plan de lancement simple

1. Jour 1 : obtenez les clés du sandbox, authentifiez-vous, récupérez le catalogue.
2. Jour 2 : passez des commandes dans le sandbox avec des clés d'idempotence et affichez les codes QR.
3. Jour 3 : ajoutez les webhooks, lancez les simulateurs de cycle de vie et d'échec.
4. Jour 4 : ajoutez les recharges et l'utilisation, puis testez sur un vrai téléphone avec une eSIM réelle.
5. Jour 5 : lancez la production.

La plupart des équipes se connectent en moins d'une semaine. Lisez la [documentation de l'API](https://docs.triposim.com) complète ou consultez notre [guide d'intégration de l'API eSIM étape par étape](/blog/esim-reseller-api-how-to-integrate-travel-esim-sales-into-your-platform).

Foire aux questions

Que doit inclure une API eSIM de voyage ?

Au minimum : authentification par jeton, clés d'idempotence, devis, flux de catalogue, codes QR/activation instantanés, webhooks signés, un sandbox avec simulateurs de cycle de vie et d'échec, les recharges, les données d'utilisation, la suspension/reprise, ainsi que des limites de débit et des codes d'erreur documentés.

Pourquoi les clés d'idempotence sont-elles importantes pour une API eSIM ?

Chaque commande d'eSIM coûte de l'argent réel. Si une requête subit un timeout et que votre système réessaie, une clé d'idempotence garantit que la tentative renvoie le premier résultat au lieu d'acheter une deuxième eSIM.

Comment tester une API eSIM sans acheter d'eSIM ?

Utilisez le sandbox. Un bon sandbox simule les commandes, l'activation, l'utilisation des données, l'épuisement et l'expiration — et vous permet de forcer des erreurs — sans débiter votre portefeuille.

Combien de temps prend l'intégration d'une API eSIM ?

Avec une API bien documentée et un sandbox complet, la plupart des équipes passent en production en 3 à 5 jours ouvrables.

L'API TripoSIM supporte-t-elle la livraison en marque blanche ?

Oui. Vous recevez le code d'activation et les données QR, de sorte que vous puissiez livrer l'eSIM dans votre propre application ou par e-mail sous votre propre marque. Voir le [programme API](/api-program).

L'essentiel

Le prix compte, mais pour une API eSIM, la vraie différence se fait sentir après le lancement : des tentatives de reconnexion qui ne facturent jamais deux fois, des webhooks auxquels vous pouvez faire confiance, et un sandbox qui vous permet de tout tester d'abord. Passez cette checklist sur n'importe quel fournisseur avant de vous engager — et [commencez par notre sandbox](/api-program) pour voir comment l'API TripoSIM Partner s'en sort.