ABA Software With an API: Who Actually Documents One
Of fourteen ABA platforms checked against their own websites, exactly one publishes open developer documentation. What exists, what's a plan-feature bullet, what's webhooks-only — and the questions that separate them.
“Does it have an API?” is the question technical buyers ask and vendor websites mostly refuse to answer. So we answered it the way this site answers things: by reading all fourteen platforms’ own websites and recording what each one actually publishes. The full five-column census (modules, pricing, integrations, compliance, API) lives in the platform comparison; this page is the API column, expanded, for the people who came here to check exactly this.
The finding: one open doc set in the entire category
CentralReach is the only vendor of the fourteen publishing developer-facing API documentation openly: OAuth 2.0 client-credentials authentication, JWT tokens, REST conventions, response codes, and endpoint reference tables, at centralreach.com/resources/api/. The documentation states that access credentials are provisioned by the implementations team through a CentralReach representative — so it’s documented-but-gated, not self-serve.
Artemis ABA lists “API access for 3rd party systems” as an included feature on both published plans — a real signal, but a plan bullet rather than documentation: what the API covers isn’t public.
Hi Rasmus documents webhooks — event pushes to external systems — and describes connections to external scheduling and practice-management tools, without general API documentation. One-directional eventing, not a read/write API, as published.
Everyone else — nothing found. Rethink Behavioral Health, CR Essentials, Motivity, AlohaABA, Theralytics, Raven Health, Portia, Noteable, Passage Health, Lumary, and Office Puzzle had no public API documentation we could locate on their sites at review. That doesn’t mean no API exists behind an NDA or a services engagement — it means you cannot verify one before buying, which for an integration-dependent practice is itself the finding.
| Platform | What’s published | What that means |
|---|---|---|
| CentralReach | Open developer docs (OAuth 2.0, REST, endpoint reference) | Verifiable before purchase; credentials gated through the vendor |
| Artemis ABA | ”API access” as a plan feature | Exists on some terms; scope not public — ask for docs |
| Hi Rasmus | Webhooks documented | Event pushes out; no published read/write API |
| The other eleven | Nothing found | Verify by asking; get any answer in writing |
Read on each vendor’s own site, 6 August 2026, as part of the platform census.
Why this column matters more than most
An API is the technical form of a question every practice eventually asks: is my data mine in practice, or only in principle? Three moments make it concrete:
Reporting and BI. The moment your questions outgrow built-in reports — payer-level margins, clinician utilization across sites — you either export CSVs by hand forever or pull via API into a warehouse or dashboard. No API means the former.
Connecting what the vendor didn’t. Payroll systems, custom intake forms, data pipelines for outcome reporting payers increasingly want — native integration lists are short in this category (most vendors don’t even name their integration partners), so the API is the general-purpose escape hatch.
Leaving. Switching platforms is bounded by what you can extract. Contractual export rights set the floor (the clause table); an API you’ve already used sets the ceiling. Practices that discover at termination that “export” means a support ticket and a zip of CSVs tend to become readers of this site.
The questions that separate a real API from a bullet point
Before weighting “has an API” in a decision, ask the vendor — in writing:
- Link me the API documentation. (If it can’t be linked, it isn’t documented.)
- Which objects are readable, and which are writable — clients, sessions, trial data, authorizations, claims?
- What auth, what rate limits, what versioning/deprecation policy?
- Is API access included in my plan, gated by tier, or priced separately?
- Can we run one integration during the trial — pull our own demo data out end-to-end?
A vendor with a real API answers all five in one email. A vendor with a checkbox answers with a meeting invite.
If the platform you love has no API
That can be a livable trade — many excellent small practices run API-less stacks — but make it deliberately: confirm the manual export covers every data type you’d need (test it now, not at termination), get export rights and retention windows in the contract, and re-ask annually; this category is consolidating, and data portability is precisely what consolidation stress-tests.
Facts trace to each vendor’s own published site as read 6 August 2026 in the platform census; this page updates with it. Vendors: publish your API docs and we’ll record it within a week — [email protected]. No vendor payment.
Frequently asked
Which ABA software has a public API?
As of our vendor-site review (6 August 2026), CentralReach is the only platform of the fourteen we checked that publishes open developer-facing API documentation — OAuth 2.0 client-credentials authentication, JWT tokens, REST conventions, response codes, and endpoint references — with credentials provisioned through a CentralReach representative. Artemis ABA lists 'API access for 3rd party systems' as an included plan feature on its pricing page, and Hi Rasmus documents webhooks without general API documentation. We did not find public API documentation on the other vendors' sites.
Why does an API matter for an ABA practice?
Three practical reasons: getting your data out on your terms (reporting, warehousing, and the exit path if you ever switch), connecting systems the vendor doesn't integrate natively (payroll, BI dashboards, custom intake), and automation as you scale. A platform without an API makes every one of those a vendor-dependency.
Is 'API access' on a pricing page the same as API documentation?
No. A plan-feature bullet tells you access exists on some terms; documentation tells you what the API can actually do — which objects, which operations, what auth, what rate limits. Before weighting the feature in a purchase, ask for the docs themselves, sample responses for the objects you care about, and whether access carries an added cost.
What about webhooks vs a full API?
Webhooks push events out (a session completed, a note signed) — useful for triggering things elsewhere, but one-directional. A full API lets you read and write on demand. Hi Rasmus, for example, documents webhooks without publishing general API documentation; whether that's enough depends on whether you need to pull data or only react to it.
Spotted something stale? Every entry shows when we last checked it. If a link is dead or an offer changed, tell us and we'll fix it.
Report a change