CentralReach stays your clinical system. The BloomText API sends and reads the messages around it.
Get started for freeSchedule a demo →Yes. CentralReach's API lets customers with an API subscription read their own data, and the BloomText API sends and reads the messages around it. You'll need three credentials from your CentralReach representative to start.
Your app reads staff, clients, and the scheduling data your API user can access through CentralReach’s API.
It looks up each patient’s BloomText conversation in a simple mapping your app keeps.
It sends reminders and replies with the BloomText API, and reads new patient replies by time range.
CentralReach stays your system of record. BloomText handles the conversations, and nothing syncs until your app connects the two.
Authenticate to CentralReach with its documented OAuth client-credentials flow and read the resources you are approved for. Then use your BloomText API key to message the matching patient and read their replies. The two systems use separate credentials.
GET https://api.bloomtext.com/v1/patient-messages?patient_id={patientId}&q=from:patient&page[limit]=50Authorization: Bearer <api-key>POST https://api.bloomtext.com/v1/patient-messagesAuthorization: Bearer <api-key>Idempotency-Key: <unique-request-key>Content-Type: application/json{"to":{"patient_id":"{patientId}"},"body":"The Thursday schedule has been updated. Check your calendar."}Send your organization’s BloomText API key in the Authorization header on every request. POST requests also need Idempotency-Key and Content-Type headers.
In CentralReach, an ABA session moves from appointment to timesheet to billing entry, tied to the client’s authorization. CentralReach’s public reference covers authentication and a staff contact call; your representative provisions the rest. These ideas assume your API user has permission for the data each one names.
CentralReach creates the billing entry only after an appointment is converted to a timesheet, and practices set a lock date for payroll. A job finds sessions still waiting for conversion a day before that date and posts a short list to each clinic’s team conversation, so RBTs close them out before billing stalls.
Uses CentralReach scheduling data your API user is approved to read
Each client’s case team usually has a BCBA, a few RBTs, and a scheduler. When your app sees a staffing change, it reads the employee’s CentralReach contact record, matches it to a BloomText user, and flags that person to add to or remove from the case-team conversation.
Uses CentralReach employee contact records
CentralReach links appointments to authorizations with start and end dates, service codes, and approved amounts. Post an internal note to the BCBA and scheduler when an authorization is close to its end date, so the reauthorization request goes in before sessions have to stop. Payer detail stays in the staff conversation, never in a caregiver text.
Uses CentralReach authorization data, if your approved access includes it
When a session is cancelled, message the caregiver’s conversation that today’s session is off, then post the open slot to the staffing conversation so a scheduler can offer it to another RBT. The standard cancellation reason stays in CentralReach.
Uses CentralReach scheduling data
Parent and caregiver training sessions are easy to forget because they sit outside the regular therapy block. Send the caregiver a reminder the afternoon before with the time and whether it is in the clinic, at home, or over telehealth.
Uses CentralReach scheduling and client data
Patient requests use your organization’s BloomText API key. Posts to a staff team conversation use an org admin’s OAuth token instead, and only reach conversations that admin is part of.
A nightly job that keeps each case-team conversation in BloomText matched to the staff CentralReach says are on the case.
POST https://login.centralreach.com/connect/tokenContent-Type: application/x-www-form-urlencodedgrant_type=client_credentials&client_id=<approved-client-id>&client_secret=<approved-client-secret>&scope=cr-apiGET https://partners-api.centralreach.com/enterprise/v1/contacts/employee/<approved-employee-id>Authorization: Bearer <approved-access-token>x-api-key: <approved-cr-api-key>Content-Type: application/jsonThe day before your timesheet lock date, tell each clinic which sessions still need converting.
POST https://api.bloomtext.com/v1/me/conversations/{clinicTeamConversationId}/messagesAuthorization: Bearer <org-admin-oauth-token>Idempotency-Key: <unique-request-key>Content-Type: application/json{"body":"Lock date is tomorrow at 5 PM. 6 sessions from this week still need converting: J.R. (Mon, Wed), A.T. (Tue), M.K. (Thu x3)."}Tell the family right away and put the open slot in front of the schedulers.
POST https://api.bloomtext.com/v1/patient-messagesAuthorization: Bearer <api-key>Idempotency-Key: <unique-request-key>Content-Type: application/json{"to":{"patient_id":"{caregiverPatientId}"},"body":"Today’s 3:00 PM session is cancelled. We will text you to reschedule."}POST https://api.bloomtext.com/v1/me/conversations/{staffingConversationId}/messagesAuthorization: Bearer <org-admin-oauth-token>Idempotency-Key: <unique-request-key>Content-Type: application/json{"body":"Open slot: today 3:00 to 5:00 PM, north clinic. Reply if you can cover."}An ABA practice runs on a lot of small checks: which sessions still need converting, whose authorization is about to end, which families need to hear about a schedule change. An agent with CentralReach data and BloomText can do those checks and send the messages.
An org admin creates an API key in BloomText. Your agent’s tools use it to message patients and read their replies, always naming the patient by ID, phone number, or MRN. The key can’t reach staff conversations; for those, the agent uses an org admin’s OAuth token, which reaches only the conversations that admin is part of.
GET https://api.bloomtext.com/v1/organizationAuthorization: Bearer <api-key>You give the agent a small CentralReach tool that gets a one-hour token with your client credentials, sends your CR API key, and calls only the endpoints your API user has permission for. CentralReach does not document an MCP server or an AI connector of its own. Third-party connectors that automate the CentralReach web app are not CentralReach products, so check them against your API Addendum before you use one.
Using CentralReach, list this week’s sessions at the north clinic that are not yet converted to timesheets. Post one summary in the north clinic team conversation in BloomText with staff initials and session times, no client names. Tomorrow at 10 AM, tell me who still hasn’t replied.Messages the agent sends with the key show the key’s name to staff, and patients see your clinic. An org admin can delete the key at any time. Read the AI agent docs.
Yes. CentralReach publishes a REST API over HTTPS with JSON at partners-api.centralreach.com, for managing practices, clients, staff, and more. The public reference covers authentication and shows one example call, reading an employee contact. The full list of endpoints you can use comes through your CentralReach representative.
Talk to your dedicated CentralReach representative. They provision a client ID and client secret for the OAuth client-credentials flow, plus a CR API key issued per organization. The API Addendum licenses the API to customers with an active API subscription, lets CentralReach set usage limits, and does not allow sublicensing.
CentralReach’s response code table says a 401 usually means the Authorization header is wrong; it should read "Authorization: Bearer" followed by your token. A 403 before authentication means the x-api-key header is missing or wrong. A 403 after authentication means your API user lacks permission for that endpoint. Tokens expire after an hour, so request a new one when calls start failing.
CentralReach has a Messages module, and families can message staff securely through the Client Portal. Its Client Portal sheet says clients can opt in to email or text notifications about those messages. Practices add BloomText when they want staff chat and caregiver texting in one place, driven from their own code through the BloomText API.
Yes, through tools you build. Your agent reaches BloomText through the BloomText API, with an organization API key. For CentralReach data, the agent calls a tool that uses your approved credentials, because CentralReach does not publish its own MCP server or AI connector.
It can be, if each system that touches the data is covered. BloomText turns on API access only for organizations with a signed BAA. On the CentralReach side, confirm your Business Associate Agreement covers the data your integration reads. Keep texts to logistics like session times and cancellations, and leave programs, goals, and payer details out.
CentralReach's API is available to customers with an active API subscription. Your representative issues a client ID, a client secret, and an API key.
API access is available to organizations with a signed BAA. Book a short call, tell us what you’re building, and we’ll turn on API access so an org admin can create your key. Don’t include PHI when you book.
Links last checked September 21, 2026.
