Skip to content
Healthcare EHR/FHIR

drchrono.com

drchrono (Tebra) sandbox and mock API

This document is intended as a detailed reference for the precise behavior of the drchrono API. If this is your first time using the API, start with our <a href="/api-docs-old/tutorial">tutorial</a>. If you are upgrading from a previous version, take a look at the changelog section. # Authorization ## Initial authorization There are three main steps in the OAuth 2.0 authentication workflow: 1. Red Writes persist, data moves on a schedule and every change can fire a signed webhook.

Operations
263
Collections
-
Event types
-
Start this simulation Vendor documentation
example request
curl https://your-drchrono.slurry.io/api/allergies \
  -H "Authorization: Bearer slurry_sim_..."

Your simulation gets its own hostname, key and IP allow-list. Built from API version v4 (Hunt Valley).

What gets simulated

Collections, relationships and state machines are worked out from the spec when you start the simulation.

  • State. Creates, updates and deletes persist and show up in later reads.
  • Behaviour. Records move through their states on a schedule you control, and you can fast-forward up to 30 days.
  • Webhooks. Every change emits a signed, retried event.
  • Failure. Per-endpoint errors, latency and chaos rules, on demand.

Operations

First 12 of 263.

  • GET/api/allergies
  • POST/api/allergies
  • GET/api/allergies/{id}
  • PUT/api/allergies/{id}
  • PATCH/api/allergies/{id}
  • GET/api/amendments
  • POST/api/amendments
  • GET/api/amendments/{id}
  • PUT/api/amendments/{id}
  • PATCH/api/amendments/{id}
  • DELETE/api/amendments/{id}
  • GET/api/appointment_profiles
drchrono (Tebra) sandbox and mock API | Slurry