Atlas API & MCP
Everything Atlas can do inside Ready Practice is also reachable from outside it. If you run your own systems — a data warehouse, an internal dashboard, a coaching app, an AI assistant of your own — they can ask Atlas the same questions your staff do, and get answers grounded in your own organization's data.
There are two ways in, and which you want depends on what is calling.
The REST API is for software you are writing. You send a question, you get an answer. It suits a report that runs nightly, a dashboard panel, or anything where you control the code making the request.
The MCP server is for AI tools that already speak Model Context Protocol — Claude and a growing number of others. Instead of you writing integration code, the tool discovers what Atlas can do and uses it directly. If your team already works in an MCP-aware assistant, this is usually the shorter path.
Both run on the same permissions and the same data. Neither is a separate copy of anything.
Getting access
API keys are issued by us rather than generated in the app, because each key is scoped deliberately: to your organization, to a set of permissions, and to a request rate. Ask your account contact and say what you're building — the scope is set to match it.
Treat the key like a password. It grants access to real client data within whatever scope it carries, so it belongs in a secrets manager, never in client-side code, a mobile app, or a repository.
A key issued for your organization cannot read another, and a request naming a different organization is refused rather than quietly ignored. If you run several organizations on Ready Practice you need a key for each — this is deliberate, so a mistake in your code cannot cross that line.
What comes back
Atlas answers the same way it does in the app: in plain language, grounded in your data, and it says so when it does not know something rather than inventing an answer.
That has a consequence worth planning around. Responses are written for a reader, not parsed as a fixed schema — so build against the meaning, not against exact wording, and don't write code that depends on a sentence being phrased a particular way.
What it will not do
The API answers questions and can prepare changes, but it does not silently change your data. Anything that alters a record is staged for a person to approve in Ready Practice, exactly as it is in the app. An integration cannot book, cancel, charge, or edit a chart on its own.
Rate limits apply per key. If you are pulling a lot on a schedule, spread the requests rather than issuing them in a burst.
A key carries permissions in the same way a staff member's role does. If a key is not scoped to health data, questions about a client's records are refused — the API is not a way around the permission model, and every access is audited the same way.
Next steps
To see what Atlas can answer before writing any code, ask it the same questions in the app — the API has the same abilities and the same limits. Start with Meet Atlas.
To have Atlas act on events rather than answer questions, look at outbound webhooks instead: they push to you when something happens, rather than waiting to be asked.
To get a key or change a key's scope, talk to your account contact with a sentence about what the integration does. Scope is set from that, so the more concrete you are, the less friction later.