Install Jentic One Beta

Connect the RSI Public Platform API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the RSI Public Platform API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fredspotinteractive.com%2Fredspotinteractive" | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fredspotinteractive.com%2Fredspotinteractive" | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with RSI Public Platform API.

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

GET STARTED

Start building with RSI Public Platform API

Explore with Jentic One

View OpenAPI Document

Use Cases

Patterns agents use RSI Public Platform API for, with concrete tasks.

★ 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.

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.

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.

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.

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

Key Endpoints

26 endpoints — 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.

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

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

Why Jentic?

What agents get from Jentic-routed access to this vendor.

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 isolation

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.

Intent-based discovery

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.

FAQs

Specific to using RSI Public Platform API through Jentic.

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.

Redspotinteractive RSI Public Platform API

AI ReadinessAI-Ready (A-)78/100

See full scorecard

Official vendor OpenAPI document · agent-readyHealthcareAppointment Schedulingbearer26 EndpointsREST

For 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.

Use for: I need to book a follow-up appointment for an existing patient, Find open slots for a new-patient visit at the downtown location next week, Check whether a caller already has a patient record at the practice, Cancel a patient's appointment and confirm the cancellation

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

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.

Jentic One on Github View OpenAPI Document

Show dimension breakdown

Foundational Compliance

Base layer of spec validity and structural soundness.

Grade: A-Signals: 4

97%

Lint Results

Aggregated quality score from linter diagnostics, weighted by severity.

100%

Resolution Completeness

Percentage of `$ref` references that resolve successfully.

Specification Validity

Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).

100%

Structural Integrity

Structural correctness score based on schema issues using logarithmic dampening.

Developer Experience & Jentic Compatibility

Clarity, completeness, and ingestion readiness for developers and tooling.

Grade: B+Signals: 4

Example Density

How richly the API is illustrated with examples.

100%

Example Validity

Percentage of examples that conform to their schemas.

74%

Response Coverage

Percentage of operations with complete response definitions (success, client error, server error).

100%

Tooling Readiness

Health of API ingestion, bundling, and resolution within Jentic pipelines.

AI-Readiness & Agent Experience

Semantic breadth, depth, and agent comprehension for AI systems.

Grade: A-Signals: 4

55%

Description Coverage

Coverage of descriptions across API elements.

100%

Error Standardization

Coverage of RFC 9457 Problem Details for error responses.

100%

OperationId Quality

Coverage, uniqueness, and casing consistency of operationIds for AI inference.

53%

Summary Coverage

Coverage of summaries across operations/tags/info.

Agent Usability

Functional utility, complexity comfort, and AI orchestration readiness.

Grade: A+Signals: 1

94%

Complexity Comfort

Agent comfort level based on API operational and structural complexity.

Security

Trust, risk posture, and security compliance.

Grade: A-Signals: 1

75%

Authentication Strength

Average quality of security schemes based on authentication method strength (weakest link for OAuth2).

AI Discoverability

Findability, semantic richness, and reasoning readiness.

Grade: ASignals: 1

83%

Descriptive Richness

Clarity and depth of descriptions across API elements.

Connect the RSI Public Platform API to your agent

Capabilities

Start building with RSI Public Platform API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs

Redspotinteractive RSI Public Platform API

Jentic AI Readiness Score

RSI Public Platform API

Foundational Compliance

Lint Results

Resolution Completeness

Specification Validity

Structural Integrity

Developer Experience & Jentic Compatibility

Example Density

Example Validity

Response Coverage

Tooling Readiness

AI-Readiness & Agent Experience

Description Coverage

Error Standardization

OperationId Quality

Summary Coverage

Agent Usability

Complexity Comfort

Security

Authentication Strength

AI Discoverability

Descriptive Richness