API RESOURCE

予約とカレンダー

Doctor- and chair-based scheduling, double-booking prevention, automatic reminders and a waitlist. Conflicts are prevented at the database level.

Early Access All API

Endpoints

10 endpoint

Endpoints for this resource. Every endpoint is scoped to the clinic data the API key is bound to; write endpoints support the Idempotency-Key header.

GET /v1/appointments Lists appointments by date range All authorized roles

POST /v1/appointments Creates a new appointment (conflict-checked) admin · secretary · physician

POST /v1/appointments/{id}/status Changes the appointment status admin · secretary · physician

POST /v1/appointments/{id}/reschedule Reschedules the appointment admin · secretary · physician

POST /v1/appointments/{id}/remind Sends an appointment reminder admin · secretary · physician

GET /v1/units Lists chairs/units All authorized roles

GET /v1/doctors Lists physicians All authorized roles

GET /v1/waitlist Retrieves the waitlist All authorized roles

POST /v1/waitlist Adds a patient to the waitlist admin · secretary · physician

DELETE /v1/waitlist/{id} Removes from the waitlist admin · secretary · physician

Example Usage

Get appointments by date range

Request

curl https://api.udentiva.com/v1/appointments?from=2026-06-24&to=2026-06-25 \
  -H "Authorization: Bearer udk_live_xxx"

Response

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"
  }
]

Security in this resource

Security isn't a feature, it's the architecture itself. The guarantees that apply to this resource:

Double booking is impossible at the database level thanks to an exclusion constraint; even in the event of an application error, a conflicting appointment cannot be written.

Concurrent slot contention is prevented with a Redis distributed lock; two requests cannot write to the same slot at the same time.

All appointment data is isolated to your clinic (RLS); status changes are recorded in the audit log.

Full security model →

Error Format

Errors are returned in a consistent envelope; the code is for the machine, the message for the user. Internal error/stack is never leaked.

{
  "error": {
    "code": "validation_failed",
    "message": "Invalid field: email"
  }
}

Other Resources

患者 Odontogram & Treatment Collections & Finance 在庫 Imaging ラボ Lead & CRM 医療ツーリズム Reporting & BI Webhooks Data Transfer (Export API)

Want early access?

Be the first to know when the API opens.

お問い合わせ