UDENTIVA Plateforme intelligente de gestion dentaire
RESSOURCE API

Rendez-vous & Agenda

Planification par praticien et par fauteuil, blocage des doubles réservations, rappels automatiques et liste d'attente. Les conflits sont empêchés au niveau de la base de données.

Accès anticipé Toute l'API

Points d'accès

10 point d'accès

Points d'accès de cette ressource. Chaque point est limité aux données du cabinet auquel la clé API est rattachée ; les points d'écriture prennent en charge l'en-tête Idempotency-Key.

GET /v1/appointments Liste les rendez-vous par plage de dates Tous les rôles autorisés
POST /v1/appointments Crée un nouveau rendez-vous (avec contrôle de conflit) admin · secrétaire · praticien
POST /v1/appointments/{id}/status Change le statut du rendez-vous admin · secrétaire · praticien
POST /v1/appointments/{id}/reschedule Replanifie le rendez-vous admin · secrétaire · praticien
POST /v1/appointments/{id}/remind Envoie un rappel de rendez-vous admin · secrétaire · praticien
GET /v1/units Liste les fauteuils/unités Tous les rôles autorisés
GET /v1/doctors Liste les praticiens Tous les rôles autorisés
GET /v1/waitlist Récupère la liste d'attente Tous les rôles autorisés
POST /v1/waitlist Ajoute un patient à la liste d'attente admin · secrétaire · praticien
DELETE /v1/waitlist/{id} Retire de la liste d'attente admin · secrétaire · praticien

Exemple d'usage

Extraire les rendez-vous par plage de dates

Requête
curl https://api.udentiva.com/v1/appointments?from=2026-06-24&to=2026-06-25 \
  -H "Authorization: Bearer udk_live_xxx"
Réponse
HTTP/1.1 200 OK
[
  {
    "id": "a1b2...",
    "patient_id": "c0ffee00-...",
    "unit_id": "u-1",
    "starts_at": "2026-06-24T10:00:00Z",
    "ends_at": "2026-06-24T10:30:00Z",
    "status": "confirmed"
  }
]

Sécurité de cette ressource

La sécurité n'est pas une fonctionnalité, c'est l'architecture elle-même. Les garanties applicables à cette ressource :

La double réservation est impossible au niveau de la base de données grâce à une exclusion constraint ; même en cas d'erreur applicative, un rendez-vous en conflit ne peut être écrit.
La concurrence sur un même créneau est évitée par un verrou distribué Redis ; deux requêtes ne peuvent écrire simultanément dans le même créneau.
Toutes les données de rendez-vous sont isolées à votre clinique (RLS) ; les changements de statut sont inscrits au journal d'audit.
Tout le modèle de sécurité →

Format d'erreur

Les erreurs sont renvoyées dans une enveloppe cohérente ; le code s'adresse à la machine, le message à l'utilisateur. Aucune erreur interne / trace de pile n'est jamais divulguée.

{
  "error": {
    "code": "validation_failed",
    "message": "Champ invalide : e-mail"
  }
}

Autres ressources

Patients Odontogramme & Traitement Encaissement & Finance Stock Imagerie Laboratoire Lead & CRM Tourisme médical Reporting & BI Webhooks Transfert de Données (Export API)
Souhaitez-vous un accès anticipé ?
Soyez le premier informé dès l'ouverture de l'API.
Contacter