Configurer et utiliser l'API REST
Interroger les rendez-vous libres et réserver des rendez-vous, directement depuis votre propre application.
L'API fonctionne avec JSON et s'appelle via l'adresse https://example.com/api.
Le processus de réservation se compose de six appels qui s'enchaînent: calendrier, motif de rendez-vous, jour, heure, champs de formulaire et enfin la réservation.
Tous les appels se font depuis votre serveur, pas depuis le navigateur de vos clients.
Étape 1: activer l'API et générer le token
À la livraison, l'API est désactivée. Vous l'activez dans l'espace d'administration.
- Cliquez dans la navigation sur Configuration.
- Cliquez dans la sous-navigation sur Paramètres généraux.
- Cliquez dans la liste sur Interface.
- Activez API activer. La modification est enregistrée immédiatement.
- Cliquez sur Générer un nouveau token pour créer le token d'accès de l'interface.
- Copiez immédiatement le token affiché et conservez-le en lieu sûr, il n'est plus affiché ensuite.
Captures d'écran
Cliquez dans la navigation sur Configuration
1
Cliquez dans la sous-navigation sur Paramètres généraux
2
Cliquez dans la liste sur Interface
3
Activez API activer. La modification est enregistrée immédiatement
4
Cliquez sur Générer un nouveau token pour créer le token d'accès de l'interface
5
Copiez immédiatement le token affiché et conservez-le en lieu sûr, il n'est plus affiché ensuite
6
Le token commence par apm_, suivi de 64 caractères, et n'est affiché qu'une seule fois. Le système ne conserve qu'un hachage, le token lui-même ne peut plus être relu par la suite.
Il y a exactement un token par installation: si vous générez un nouveau token, l'ancien perd immédiatement sa validité.
Vous envoyez le token à chaque appel dans l'en-tête de la requête:
Authorization: Bearer apm_votre-token
Étape 2: vérifier la connexion et interroger les calendriers
Le premier appel vous permet de vérifier la connexion et d'obtenir les numéros de vos calendriers de rendez-vous.
curl -H "Authorization: Bearer apm_votre-token" \
https://example.com/api/schedules
Réponse:
{
"data": [
{ "id": 1, "name": "Site principal" },
{ "id": 2, "name": "Filiale" }
]
}
Vous utilisez l'id du calendrier souhaité dans tous les autres appels comme paramètre schedule.
Étape 3: interroger les motifs de rendez-vous
curl -H "Authorization: Bearer apm_votre-token" \
"https://example.com/api/reasons?schedule=1"
Réponse:
{
"data": [
{
"id": 1,
"name": "Entretien de conseil",
"description": "Conseil standard",
"duration": 1800
},
{
"id": 2,
"name": "Rendez-vous de suivi",
"description": "",
"duration": 900
}
]
}
duration est la durée en secondes (1800 secondes correspondent à 30 minutes).
Vous utilisez ensuite l'id comme paramètre reason. Si aucun motif de rendez-vous n'est configuré pour un calendrier, data est vide.
Étape 4: interroger les jours avec des rendez-vous libres
curl -H "Authorization: Bearer apm_votre-token" \
"https://example.com/api/days?schedule=1&reason=1"
Réponse:
{
"data": ["2026-05-23", "2026-05-24", "2026-05-26"]
}
Seuls sont renvoyés les jours où au moins un horaire de rendez-vous est libre. Les paramètres de votre calendrier déterminent jusqu'où la liste s'étend dans le futur.
Étape 5: interroger les heures libres d'un jour
curl -H "Authorization: Bearer apm_votre-token" \
"https://example.com/api/slots?schedule=1&reason=1&day=2026-05-23"
Réponse:
{
"data": [
"2026-05-23 09:00:00",
"2026-05-23 09:30:00",
"2026-05-23 10:00:00"
]
}
Les heures sont les heures locales de votre installation, le format est toujours AAAA-MM-JJ HH:MM:SS.
Étape 6: interroger les champs de formulaire de la réservation
Les champs nécessaires à une réservation, c'est vous qui les définissez dans le planificateur de rendez-vous. Interrogez donc toujours les champs au lieu de les inscrire en dur dans votre propre programme.
L'espace dans le paramètre slot doit être encodé en %20.
curl -H "Authorization: Bearer apm_votre-token" \
"https://example.com/api/forms?schedule=1&reason=1&slot=2026-05-23%2009:00:00"
Réponse:
{
"data": {
"first_name": {
"form_type": "textbox",
"input_type": "text",
"label": "Prénom",
"required": true,
"value": ""
},
"last_name": {
"form_type": "textbox",
"input_type": "text",
"label": "Nom",
"required": true,
"value": ""
},
"email": {
"form_type": "textbox",
"input_type": "email",
"label": "Adresse e-mail",
"required": false,
"value": ""
}
}
}
Tous les champs avec "required": true doivent être remplis lors de la réservation. Le champ password n'est jamais renvoyé par l'API.
Étape 7: réserver le rendez-vous
La réservation est le seul appel avec la méthode POST. L'en-tête doit contenir Content-Type: application/json.
Dans submission, vous indiquez les valeurs correspondant aux noms de champs de l'étape 6.
curl -X POST https://example.com/api/bookings \
-H "Authorization: Bearer apm_votre-token" \
-H "Content-Type: application/json" \
-d '{
"schedule": 1,
"reason": 1,
"slot": "2026-05-23 09:00:00",
"submission": {
"first_name": "Hans",
"last_name": "Pitt",
"email": "hans.pitt@example.com"
}
}'
Réponse en cas de succès (statut 201):
{
"booking_id": 142,
"booking_details_id": "a3f8c2d1e5b6",
"user_id": 87,
"slot": "2026-05-23T09:00:00Z"
}
booking_id: le numéro du rendez-vous pour vos propres dossiersbooking_details_id: l'identifiant avec lequel votre client peut consulter les détails de son rendez-voususer_id: la fiche client créée lors de la réservationslot: le début du rendez-vous, ici en UTC selon ISO 8601
Le rendez-vous est ainsi enregistré dans le planificateur. Les e-mails de notification sont envoyés comme pour toute autre réservation.
Messages d'erreur
Les erreurs sont également renvoyées en JSON, par exemple {"error":"Unauthorized"}.
- 400 Invalid request:
scheduleoureasonn'est pas un nombre,slotn'a pas le formatAAAA-MM-JJ HH:MM:SSousubmissionmanque. - 400 Invalid JSON: les données envoyées ne sont pas du JSON valide.
- 400 Required field empty: un champ obligatoire de l'étape 6 manque. Le champ concerné est indiqué dans
field. - 401 Unauthorized: le token manque, est incorrect ou a été remplacé par un nouveau. Certains serveurs suppriment l'en-tête
Authorization; en cas de doute, demandez à votre hébergeur. - 404 Schedule/Reason/Day/Slot not found: le numéro demandé, le jour ou l'heure n'est plus disponible.
- 404 Not found: l'adresse est incorrecte, ou un paramètre manque ou a un format incorrect. Les paramètres manquants ne produisent donc pas une erreur 400, mais 404.
- 415 Unsupported Media Type: lors de la réservation,
Content-Type: application/jsonmanque. - 429 Too Many Requests: la limite de 300 requêtes par minute est atteinte. L'en-tête
Retry-Afterindique le temps d'attente en secondes. - 500 Failed to create user/appointment: le rendez-vous n'a pas pu être enregistré.
- 503 API disabled: l'API n'est pas activée (voir l'étape 1).
- 503 Not configured: l'installation n'est pas encore terminée.
Remarques
- L'ordre des appels est impératif: chaque appel fournit l'information dont le suivant a besoin.
- Les heures sont envoyées en heure locale, la réponse de la réservation contient le rendez-vous en UTC.
- Entre l'interrogation d'une heure libre et la réservation, le rendez-vous peut être pris par quelqu'un d'autre. Dans ce cas (erreur 404 Slot not found), interrogez de nouveau les heures libres.
- Les calendriers et les motifs de rendez-vous changent rarement et peuvent être mis en cache. Les jours et les heures libres doivent être interrogés à chaque fois.
- L'API est prévue pour la communication entre serveurs. Aucun en-tête CORS n'est envoyé, un appel direct depuis le navigateur n'est donc pas possible. Le token ne doit pas être intégré dans un site web ou une application.
- Chaque réservation crée une fiche client. Les rendez-vous issus de l'API sont reconnaissables dans le planificateur à la source
api. - Ne sont pas inclus pour le moment: l'annulation et le déplacement de rendez-vous, la lecture des rendez-vous existants ainsi qu'une sortie page par page. Pour les messages automatiques vers des systèmes externes, utilisez le module Webhooks.
- La référence technique complète avec tous les paramètres, codes de statut et schémas est disponible sous Référence de l'API REST, la description lisible par machine selon OpenAPI 3.1 sous openapi.json. Les deux fichiers se trouvent aussi dans votre propre installation, sous
https://example.com/api/docs.htmlethttps://example.com/api/openapi.json.
Retour à l'aperçu: Module "API (interface)".