Message patients and read their replies from your EMR integration. Every request is authenticated with your organization’s BloomText API key.
Get started for freeSchedule a demo →Yes. Any EMR with an API can connect to BloomText: your app reads schedules or patients from the EMR and sends messages with the BloomText API. BloomText handles the messaging, and your EMR stays the system of record.
Your app reads patients and appointments through your EMR’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.
Your EMR stays your system of record. BloomText handles the conversations, and nothing syncs until your app connects the two.
Start from the vendor’s own documentation or partner terms. On the BloomText side, read the API reference for API keys, patients, and sending messages. Then match vendor records to BloomText patients by MRN.
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":"Your appointment is confirmed for Tuesday at 10:00 AM."}Send your organization’s BloomText API key in the Authorization header on every request. POST requests also need Idempotency-Key and Content-Type headers.
Most EMR integrations follow the same shape: read a schedule or patient record from the EMR, find the matching BloomText patient by MRN or phone number, and send them a message or read their replies.
A nightly job reads tomorrow’s appointments from your EMR and sends each patient a reminder in their BloomText conversation. Replies land in the same thread your front desk already works from.
Uses your EMR’s appointment and patient data
When a new patient is booked but their intake packet is still open in the EMR, send a short nudge with the link your practice already uses. Stop nudging once the EMR marks the forms complete.
Uses your EMR’s appointment status and forms status
Post into an internal BloomText group when something in the EMR needs a person: a same-day cancellation, a new referral, or an unsigned note. Staff discuss it where they already talk.
Uses your EMR’s schedule changes and task lists
Check each reminded patient’s BloomText messages for replies and route them. A “C” reply to a reminder can confirm the appointment in the EMR, while anything else goes to a staff queue.
Uses your EMR’s appointment confirmation field
Pull a patient’s messages for a date range on a schedule and attach them to the patient’s chart, so the EMR holds a copy of what was said by text.
Uses your EMR’s document upload endpoint
A scheduled script that reminds every patient booked for tomorrow.
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":"Reminder: you have an appointment tomorrow at 9:30 AM. Reply C to confirm."}A small job that turns patient replies into confirmations.
GET https://api.bloomtext.com/v1/patient-messages?after={lastChecked}&q=from:patientAuthorization: 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":"Thanks, you’re confirmed."}An AI agent with access to both systems can handle the routine back-and-forth for a front desk: answering scheduling questions, sending reminders, and handing anything clinical to a person.
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>Give the agent a small tool that calls your EMR’s API with your approved credentials, such as “look up tomorrow’s appointments” or “mark appointment confirmed.” Keep those tools narrow and read-only where you can. On the BloomText side, the agent calls the BloomText API with your organization’s API key, always naming the patient.
q=from:patient on their messages.When a patient asks about their next appointment, look it up in the EMR and reply to them in BloomText with the date and time. If they ask anything clinical, don’t answer. Add the patient to the “Needs staff reply” list in our app.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. You write a small integration that reads from your EMR’s API and calls the BloomText API. BloomText handles the messaging side: patients, messages, delivery status, and campaigns, with an organization API key. Store each EMR patient’s ID as the BloomText patient’s MRN.
Many EMRs gate API access behind a partner program, an admin request, or a paid add-on. Ask your EMR vendor for its approved access process. You can still build the BloomText side first and plug in the EMR data once access is approved.
Yes. The API sends a message to a patient by patient ID or phone number, and a new number creates the patient. Messages go by secure link by default, or plain SMS if you ask, and every message lands in a BloomText conversation your staff can see.
Yes, with an agent you build. Have an org admin create a BloomText API key, and give the agent tools that call the BloomText API and your EMR’s API. Every BloomText call names the patient, and messages it sends show the key’s name to staff.
BloomText only gives API access to organizations with a signed BAA, and every message stays inside a BloomText conversation your staff can audit. Keep message content to what the patient needs, such as appointment times, and follow your own EMR vendor’s terms for the data you read.
Every EMR vendor controls its own API access. Some offer free certified APIs, and others require a partnership, a paid add-on, or an admin request.
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.
