canonical: https://jentic.com/apis/redspotinteractive.com/redspotinteractive

# Redspotinteractive RSI Public Platform API

The RSI Public Platform API books, cancels, and confirms patient appointments for a single medical practice, working against the practice-management system behind it, currently Nextech Select or Modernizing Medicine. It matches or creates patient records, lists the locations, providers, visit types, and procedures offered for online scheduling, and searches bookable slots in a date window. Clients flagged confirmation_required perform each mutation in two phases: a 428 response returns a confirmationToken and a readBack, and an identical resend with the token completes the change. Errors come back as RFC 7807 problem+json with a stable machine code.

## For AI agents

Find a patient, search open slots for a visit type and procedure at a practice location, and book, confirm, or cancel the appointment through a two-phase confirmation flow built for LLM agents.

## Scope

Does not handle clinical charting, billing, insurance claims, or e-prescribing. Use for patient lookup and appointment scheduling at one practice only.

## Capabilities

- Match exactly one patient by firstName, lastName, phone, and dob with POST `/patients/match` before booking
- Search bookable slots with GET /slots by LocationId, VisitTypeId, ProcedureId, and a From/To date window
- Book a slot for a patient with POST /appointments, passing patientId and slotId and resending with the confirmationToken
- Cancel or confirm attendance for an existing appointment through its appointmentId path
- Read the practice profile with GET /practice, including locations and hours, providers, visit types, policies, and insurances
- List the locations, providers, and visit types offered for online booking under /scheduling
- Create or update a patient record in the practice's scheduling system

## Use cases

### AI front-desk agent booking appointments through Jentic

A practice's AI phone or chat assistant books visits without a developer hand-wiring OAuth and the two-phase confirmation flow. Through Jentic the agent searches for 'book a patient appointment', loads POST /appointments with its schema, and handles the 428 challenge by checking the readBack against the caller's request before resending the identical body with the confirmationToken. The resend is idempotent, so a retry after a network failure replays the stored result instead of double-booking.

Example prompt: Call POST `/patients/match` with the caller's firstName, lastName, phone, and dob, search GET /slots for the chosen LocationId, VisitTypeId, ProcedureId, From, and To, then POST /appointments with patientId and slotId and resend with the returned confirmationToken

### Online self-scheduling for a specialty practice

A patient-facing booking page needs to show only what the practice offers online. GET `/scheduling/locations`, GET `/scheduling/providers`, and GET `/scheduling/visit-types` return the bookable options, and GET `/visit-types/{visitTypeId}/procedures` lists the procedures paired with each visit type. GET /slots then returns open times for that combination, and GET `/slots/{slotId}` reads live availability before the patient commits.

Example prompt: List visit types with GET `/scheduling/visit-types` for a locationId, fetch procedures via GET `/visit-types/{visitTypeId}/procedures`, then search GET /slots for the next 14 days and return the first five open times

### Appointment reminders and cancellations

A reminder workflow reads a patient's upcoming visits with GET /appointments filtered by PatientId and a From/To window. When the patient replies to confirm, POST `/appointments/{appointmentId}/confirm` records attendance; when they cannot make it, POST `/appointments/{appointmentId}/cancel` frees the slot. A 409 on rebooking means the slot was taken, so the workflow re-runs the slot search and offers new times.

Example prompt: List appointments with GET /appointments for PatientId 'p-1042' from today to seven days out, then POST `/appointments/{appointmentId}/confirm` for the visit the patient confirmed

### Practice directory answers

Callers ask about hours, providers, insurance, and hospital affiliations before booking. GET /practice returns the practice's contact details, locations and hours, providers, visit types and procedures, staff directory, policies, insurances, and hospital affiliations in one read, and GET `/providers/{providerId}/business-hours` returns a single provider's schedule.

Example prompt: Call GET /practice to read accepted insurances and locations, then GET `/providers/{providerId}/business-hours` for the provider the caller asked about

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/patients/match` | Match one patient by demographics |
| GET | `/slots` | Search bookable slots |
| POST | `/appointments` | Book a slot for a patient |
| POST | `/appointments/{appointmentId}/cancel` | Cancel an appointment |
| POST | `/appointments/{appointmentId}/confirm` | Confirm attendance |
| GET | `/scheduling/visit-types` | List bookable visit types and procedures |
| GET | `/practice` | Read the practice profile and directory |

## Key resources

- **Patients** — Search, match by demographics, create, read, and update patient records
- **Slots** — Search bookable slots by location, visit type, procedure, and date window, and read a single slot's live availability
- **Appointments** — List a patient's appointments, book a slot, read one appointment, and cancel or confirm it
- **Scheduling directory** — Locations, providers, visit types, and procedures offered for online booking
- **Practice** — Practice profile with locations, hours, providers, policies, insurances, and hospital affiliations

## AI readiness

This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.

- **Score:** 78 / 100
- **Maturity:** AI-Ready
- **Dimensions:**
  - Foundational Compliance: 74 / 100
  - Developer Experience & Jentic Compatibility: 69 / 100
  - AI-Readiness & Agent Experience: 77 / 100
  - Agent Usability: 94 / 100
  - Security: 75 / 100
  - AI Discoverability: 83 / 100
- **View full report:** https://jentic.com/apis/redspotinteractive.com/redspotinteractive/scorecard
- **How the score is calculated:** https://docs.jentic.com/reference/api-readiness-framework/overview/
- **More about the dimensions:** https://docs.jentic.com/reference/api-readiness-framework/specification/#dimensional-model-overview

### Score it yourself

Every API in the directory is allowlisted, so you can re-score it with no key required.

- **Score your own API:** https://jentic.com/scorecard.md
- **Scoring CLI agent skill:** https://github.com/jentic/jentic-api-scorecard/blob/main/skills/jentic-api-scorecard/SKILL.md

```sh
npx @jentic/api-scorecard-cli score <openapi-url>
```

## Why Jentic

- **Setup:** Wiring the RSI API by hand means running the OAuth client-credentials flow for a practice-scoped token, handling the 428 confirmation round trip on every mutation, and parsing problem+json error codes. Through Jentic you install once, import the RSI Public Platform API from the API Directory, store the token once, and your agent calls it.
- **Permission scoping:** RSI puts appointment, patient, and provider ids in the URL path (`/appointments/{appointmentId}/cancel`, `/patients/{patientId}`), so rules bound the agent by operation and path. You choose the operations it may call, so changes like cancelling appointments or updating patient records are not included unless you add them.
- **Credential handling:** Your RSI access token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'find open appointment slots' or 'book a patient appointment', and Jentic returns the matching RSI operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Zocdoc API** — Marketplace booking across many practices rather than one practice's own scheduling system
- **DrChrono API** — EHR and practice-management API with its own appointment and patient resources
- **athenahealth API** — Broad EHR and practice-management API covering clinical records as well as scheduling
- **Calendly API** — General-purpose scheduling links for non-clinical meetings

## FAQ

### What authentication does the RSI Public Platform API use?

Per its OpenAPI spec, the RSI Public Platform API authenticates every operation with an HTTP bearer token: an OAuth access token issued to a client-credentials integration and scoped to one practice. GET /capabilities echoes the scopes granted to the token. Through Jentic, the token is held encrypted by your own Jentic One instance and injected at call time, so it never enters the agent's context.

### How does the two-phase confirmation work when booking with the RSI API?

For clients flagged confirmation_required, the first POST /appointments returns 428 with a confirmationToken and a readBack describing the booking. Check that the readBack matches the patient's request, then resend the byte-identical body with the confirmationToken added, and a 201 returns the appointmentId. Resending the same confirmed body and token replays the stored result, so a retry never double-books.

### What are the rate limits for the RSI Public Platform API?

The OpenAPI spec does not specify numeric rate limits. Check the RSI developer documentation at https://docs.redspotinteractive.com/ for current limits before running bulk slot searches.

### Is there an RSI Public Platform MCP server?

You don't need an MCP server to give your agent the RSI Public Platform API. Jentic connects it directly from the API Directory: import it, store your access token once, and your agent calls the scheduling operations it needs, discovered on demand rather than loaded into its context up front.

### How do I book an appointment with the RSI API through Jentic?

Search Jentic for 'book a patient appointment', then run POST `/patients/match` to get the patientId, GET /slots with LocationId, VisitTypeId, ProcedureId, From, and To to pick a slotId, and POST /appointments with both ids, resending with the confirmationToken if a 428 comes back. To run it on your own infrastructure, install Jentic One from its GitHub repo.

### Can I limit what my agent is allowed to do with the RSI API?

Yes. For a booking assistant, write a rule that allows patient match, the slot search and slot read, and the appointment booking operation, and leaves out cancel and patient update. The agent can then find a patient and book a visit, but a cancellation or record change is outside its bounds, and every call it makes is logged.