Mode sandbox

La sandbox est un environnement de test isolé : mêmes endpoints, mêmes SDK, mêmes widgets, mais des données séparées de la production. Vous pouvez y créer, réserver, casser et recommencer sans conséquence.

Comment on y bascule

Par le préfixe de la clé. Il n'y a pas d'URL différente à retenir : une clé pk_test_ atteint les mêmes routes /api/... qu'une clé pk_live_, et le serveur la route vers l'instance sandbox.

Préfixe	Environnement
pk_live_	Production
pk_test_	Sandbox

Conséquence pratique : changer d'environnement = changer de clé. Aucune ligne de code à modifier.

JavaScript / TypeScript

// Production
const client = new MitoeraClient({ keyId: 'pk_live_xxx', secret: 'sk_xxx' });

// Sandbox — même code, autre clé
const client = new MitoeraClient({ keyId: 'pk_test_xxx', secret: 'sk_xxx' });

PHP

// Production
$client = new MitoeraClient(['keyId' => 'pk_live_xxx', 'secret' => 'sk_xxx']);

// Sandbox — même code, autre clé
$client = new MitoeraClient(['keyId' => 'pk_test_xxx', 'secret' => 'sk_xxx']);

Widget

<!-- Le widget bascule pareil : seule la clé publique change -->
<script>
  new Mitoera.SeatingChart({
    divId: 'mitoera-chart',
    workspaceKey: 'pk_test_xxxxxxxx',
    event: 'concert-12-mars',
  }).render();
</script>

Comment l'aiguillage fonctionne

La bascule se fait au niveau du reverse proxy, avant même d'atteindre l'application. Deux règles, dans cet ordre :

1. En-tête X-Api-Mode: sandbox → instance sandbox.
2. En-tête Authorization: Basic … dont la clé commence par pk_test_ → instance sandbox.

Sinon, production. C'est pour cela qu'aucune URL ne change : même hôte, même préfixe /api, seul le contenu de l'en-tête d'authentification décide.

Conséquence utile à connaître : si vous appelez l'API autrement qu'en Basic — typiquement avec un JWT — le préfixe de clé n'est plus visible pour le proxy, et l'en-tête X-Api-Mode devient le seul moyen d'atteindre la sandbox.

Le header X-Api-Mode

C'est exactement le cas de POST /api/auth/embed-token, utilisé par l'éditeur embarqué : la clé y voyage dans le corps de la requête, pas dans l'en-tête Authorization.

POST /api/auth/embed-token
Content-Type: application/json
X-Api-Mode: sandbox

Le SDK navigateur ajoute ce header tout seul quand le keyId commence par pk_test_. Vous n'avez à y penser que si vous appelez cet endpoint à la main.

Ce qui diffère de la production

	Production	Sandbox
Données	Réelles	Isolées, réinitialisables
Endpoints	https://api.mitoera.com/api	Identiques
Clés	pk_live_	pk_test_
Facturation	Sièges comptabilisés	Non comptabilisés

Réinitialiser la sandbox

Une remise à zéro rend l'instance sandbox à son état initial. C'est pratique avant une démonstration ou une campagne de tests automatisés — à condition de savoir ce qu'elle emporte.

Un reset efface aussi les clés API sandbox

La remise à zéro ne se limite pas aux données de test, et ne se limite pas à votre workspace : elle vide l'instance sandbox entière.

Effacé	Conséquence
Plans, catégories, événements, sièges	Contenu de test à recréer
Clés API	Vos clés pk_test_ cessent de fonctionner — il faut en générer de nouvelles
Comptes utilisateurs	Les accès sandbox sont à recréer
Paramètres	Retour aux valeurs par défaut, durée de hold comprise

Conséquence pratique : une clé pk_test_ qui se met soudainement à répondre 401 sans avoir été révoquée a probablement été emportée par un reset.

Les clés API n'expirent pas

Il n'existe aucun mécanisme d'expiration : une clé est active jusqu'à ce qu'elle soit explicitement désactivée, ou supprimée. Si une clé cesse de fonctionner, cherchez du côté d'une désactivation dans le back-office ou d'un reset sandbox — jamais d'une date de péremption.

La production n'est jamais concernée : l'opération est refusée si l'instance visée n'est pas la sandbox.

Conseils de test

Rejouez le guide de démarrage en sandbox. Le Démarrage rapide fonctionne à l'identique avec une clé pk_test_ : c'est la meilleure façon de valider une intégration avant de la brancher en réel.

Testez les cas d'échec. Réservez deux fois le même siège pour voir le 409, appelez avec une clé révoquée pour voir le 401, visez une ressource d'un autre workspace pour voir le 403. Votre code d'intégration doit gérer ces trois cas — voir Codes d'erreur.

Testez l'expiration des holds. Réduisez la durée de hold dans les paramètres, sélectionnez des sièges, attendez : vérifiez que votre interface réagit bien quand les sièges redeviennent available.