Pour les développeurs et les intégrateurs
Une API de réservation, et un serveur MCP par-dessus.
Tout ce que fait le back-office passe par la même API publique : disponibilités, rendez-vous, clients, prestations, ressources, horaires, paiements. Il n’y a pas d’API de second rang.
La description OpenAPI complète est servie en clair, sans compte et sans formulaire.
Ce qu’il faut lire en premier
L’authentification est un jeton porteur dans l’en-tête Authorization. Chaque clé porte des permissions explicites, et une clé de widget public ne peut faire que ce qu’un visiteur a le droit de faire.
- https://sutempo.com/openapi.json : la description OpenAPI complète de l’API, servie sous /v1
- https://sutempo.com/.well-known/platform-capabilities.json : le manifeste des capacités réellement exposées par ce déploiement
- https://sutempo.com/llms.txt : le même résumé, pour un assistant
- https://sutempo.com/console : la console qui délivre les clés d’API, après connexion
Le trajet minimal d’une réservation
Lire les disponibilités, poser une réservation temporaire le temps du paiement, puis confirmer. Le créneau n’est jamais calculé côté client : le serveur ne propose que des débuts postérieurs à son horloge, et une réservation temporaire empêche deux clients de prendre le même créneau.
curl -H "Authorization: Bearer $SUTEMPO_KEY" \
"https://sutempo.com/v1/business-tenants/$TENANT/availability?serviceId=$SERVICE&from=2026-10-01"
curl -X POST -H "Authorization: Bearer $SUTEMPO_KEY" \
-H "Content-Type: application/json" -H "Idempotency-Key: $(uuidgen)" \
-d '{"serviceId":"...","startsAt":"2026-10-01T09:00:00Z"}' \
"https://sutempo.com/v1/business-tenants/$TENANT/appointments/hold"Le serveur MCP
Le paquet @platform/mcp-server expose la configuration d’un commerce comme des outils pour un agent. Le contrat impose de prévisualiser avant d’appliquer : un agent lit la configuration, propose une modification, en montre les effets, et ne l’applique qu’ensuite.
Ce n’est pas une précaution de façade. La prévisualisation renvoie la liste des changements destructifs, et l’application est refusée si la configuration a bougé entre les deux appels.
- describe_capabilities, list_business_tenants, list_tenant_modules : ce que ce déploiement sait faire
- get_current_blueprint, get_blueprint_version : l’état courant et sa version
- preview_blueprint_changes puis apply_blueprint_changes : proposer, puis appliquer
- schedule_group_sessions, cancel_group_session : les séances collectives
- get_translation_status, set_translation_override : les langues de la page publique
Intégrer la réservation dans un site
Deux chemins, selon ce que vous construisez. Le widget embarquable se pose sur un site existant avec une clé publique et hérite de la langue de la page. Le SDK JavaScript et l’API sous-jacente laissent construire un parcours entièrement à votre main, y compris le paiement.
Dans les deux cas, les paiements vont sur le compte Stripe du commerce, jamais sur un compte intermédiaire.
Questions fréquentes
L’API est-elle payante ?
L’accès à l’API suit l’abonnement du commerce. Il n’y a pas de tarif séparé pour les développeurs, et pas de limitation de fonctions par rapport au back-office.
Comment obtenir une clé ?
Depuis la console développeur, après connexion au compte du commerce. Les clés se créent, se font tourner et se révoquent par l’API comme par la console.
Les requêtes de création sont-elles idempotentes ?
Oui, les écritures acceptent un en-tête Idempotency-Key, ce qui rend un nouvel essai après une coupure réseau sans danger.
Le serveur MCP peut-il modifier un commerce sans contrôle ?
Non. Le contrat impose d’appeler la prévisualisation avant l’application, et l’application échoue si la configuration a changé entre-temps.
Y a-t-il des webhooks ?
Oui, le transport de webhooks fait partie de la plateforme et se configure comme le reste, par l’API.
Commencez gratuitement.
Créer mon compteSolo est gratuit, sans carte bancaire. Établissement et Membership s’essaient 30 jours, et l’activité revient en Solo à la fin de l’essai sans perte de données.