Start from the Demo App

The Demo App is a public GitHub template: a complete Next.js Vim app with the OAuth flow, SDK initialization, and an SDK Explorer that drives every capability your manifest declares. Forking it is the fastest way to see real EHR data flowing through the SDK — and the fastest way to find out whether a capability you need is actually available in the EHR you care about.

gh repo create my-vim-app --template vimconnect/vim-demo-app --private --clone
cd my-vim-app
npm install

Then set the three required variables and run it:

APP_ENV=local              # local | staging | production
CLIENT_ID=your_client_id
CLIENT_SECRET=your_client_secret   # server-only, never exposed to the browser

npm run dev            # http://localhost:8080

Your client ID and secret come from an environment on your app in the Vim Console — see Getting your client ID and secret. The app fails fast with a named error if any required variable is missing, rather than falling back to a default and misbehaving later.

What it demonstrates

• The full OAuth handshake — /launch receives the launch_id, redirects to Vim's authorize endpoint, exchanges the code for a token server-side at /token, then initializes the SDK. This is the flow described in Authentication, written out end to end.
• The SDK Explorer — it reads the operations your app manifest declares, watches live EHR context, and the moment the context surfaces the ids an operation needs, it fires that read and shows you the raw response. Writes never auto-fire; they arm and wait for an explicit click.
• Capability and permission handling — every call goes through the same getCapability / hasPermission checks your app should be doing, so you can see exactly what a given EHR does and does not support.
• Worker apps and the offscreen surface — /offscreen covers the headless variant described in Worker Apps.

Fork it, or start from scratch?

Fork the Demo App when you want to see the platform working before you commit to a design, when you are evaluating which capabilities a target EHR actually implements, or when you are debugging your own app and need a known-good reference to compare against.

Follow the Quick Start when you already know what you are building and want the minimum viable app — it builds the launch page, the token exchange, and a single chart-open subscription from an empty create-next-app, with nothing else in the way.

Most teams do both: fork the demo app to learn the surface, then start their real app from the Quick Start.

Next Steps

• Using These Docs with AI — point your coding agent at the real reference
• Testing against the Sandbox EHR — run your fork against a real EHR context
• EHR Support Matrix — which capabilities exist in which EHR