latestOpenAPI 3.0.02026-08-232861531.0 MB

d3c75c2a2f1d

appointments5

appointmentTypes5

assistantActions5

assistantInstances8

assistantTransferRules1

auth5

availabilities4

billingCharges4

billingCopays6

Broadcast Templates6

broadcastEvents4

broadcastFlows9

campaigns4

chatActivities4

chatActivitiesReasons5

chatAudits5

checklists7

checklistTemplates8

customWebStyles5

engagementEvents2

engagements8

engagementSettings5

estimates5

facilities5

fileUploads5

groups5

insurancePayors7

insurances5

knowledgeBaseQuestionAnswers5

lumabotFlows12

lumabotFlowTemplates5

messages4

messageTemplatePartials5

offers5

outboundReferrals5

patientCreditCards5

patientFormPdfFilledDocuments5

patientFormPdfTemplates5

patientForms4

patientFormTemplates6

patientMessageTemplates5

patients6

providers5

providerSchedulingGroups5

queueManagerInstances1

recalls5

referrals6

reminders5

reports5

schedulers1

settings3

specialties14

squigglies1

systemAudits1

users5

waitlists5

messages

Create message

post/messages

Request body

patientstring required

The ID of the patient linked to this message.

key'chatRequest' | 'chatRequestInsecure'

The MessageTemplate name. There are only 2 templates available through the RESTful API. The secure template means that the patient only gets a generic message with a link to open the patient web app and then read the real message. In that case, there are 2 messages, one with that generic message, and one with the real message. This parameter is set automatically on the message, depending on the secure parameter which was chosen when the message was created.

type'inbound' | 'outbound' required

Indicates if a message was sent from Luma to an external person, or the other way around.

voiceAnsweredBy

ref'chat' required

On our RESTful API, you can only create messages with ref chat, but you may see these other refs when fetching messages. Indicates what this message is about. Depending on this value, you also know what the parameter refId refers to.

chat (refId will be the ID of a ChatActivity)

refIdstring

The ID of the object referenced by the ref parameter.

patientMessageTemplatestring

The ID of a Hub Message Template (or PatientMessageTemplate). These are custom messages, created by users, to make their typing experience easier.

language'ar' | 'bn' | 'cn' | 'de' | 'en' | 'es' | 'fa' | 'fl' | 'fr' | 'gr' | 'gu' | 'hi' | 'ht' | 'hy' | 'it' | 'ja' | 'km' | 'ko' | 'mr' | 'my' | 'pa' | 'pl' | 'pt' | 'ru' | 'so' | 'th' | 'ti' | 'ur' | 'vi' | 'zh-t' | 'zh'

Language

channel'chat' required

description: | The channel used to send this message. On our RESTful API, you may search for multiple channels, but only POST chat messages. Check the response format to see other possible channels. Two of them deserve an explanation:

chat will check the recipient's contact and pick the channel automatically.
inapp are meant for internal messages, when a staff user @mentions another staff user on Hub. The mentioned person only gets a notification on their browser window, by fetching from the notifications API.

shouldForceContactWithNotifyToboolean

When the patient has the patient web app open, we detect that and only send messages through the web interface. This is to avoid having the patient receive the same message both on the web and also by SMS. But if this flag is set to TRUE, then we will send to the contact specified in the notifyTo field, regardless of the patient's online presence.

textstring required

The content of the message. On our RESTful API, you can only POST messages with channel chat, and you must provide a text. Just as an information for when fetching messages (not creating them), all the other channels determine the text automatically, based on the key. The key is the name of a messageTemplate, which is fetched then parsed (for squigglies) to generate the final text automatically.

secureboolean required

Indicates how a message with channel chat will be delivered. Secure messages are created on the database but not really sent to patients. Instead, we create another unsecure message whose content is the messageTemplate chatRequestInsecure, which basically instructs the patient to click on a link to open patient-web-app to log in and then read the secure message. Insecure messages are sent directly to patients. Their text should not contain any PHI or sensitive information.

automatedboolean

Indicates if a message was created by users (chat) or by the system (reminders, recalls, etc).

visibility'public' | 'private' | 'internal'

Helps determine where a certain message should be displayed.

public = manual and automated messages sent to patients, visible to patients logged into our patient web app;
private = automated messages sent to staff, only visible to one recipient staff user;
internal = manual messages sent from staff to staff, visible to both staff users involved in a conversation, whenever one @mentined the other, both logged into our internal web app, and usually on Hub rather than any notification areas.

filestring

The ID of a FileUpload, in case this message has any attachment, sent via the FileUpload RESTful API.

recipientstring

The ID of the User receiving the message. Usually, for messages type outbound, the recipient is the ID of a patient.

recipientType'doctor' | 'staff' | 'patient'

The type of the user in the field recipient

appointmentstring

ID of Appointment

providerstring

ID of Provider

appointmentTypestring

ID of AppointmentType

followupstring

ID of Followup or Custom Action

recallstring

ID of Recall

referralstring

ID of Referral

messageFailurestring

ID of MessageFailure

Response

Successful creation

_idstring

Luma's internal ID of an object.

userstring

The ID of the root account user.

deleted0 | 1

Flag for logical deletion where 1 means deleted.

createdBystring

The ID of the user who created this object.

updatedBystring

The ID of the user who updated this object.

createdAtstring date-time

The date/time when this object was created.

updatedAtstring date-time

The date/time when this object was updated.

patientstring

The ID of the patient linked to this message.

keystring

fromstring

the phone number or e-mail address from whom this message was received. It depends on the value of the parameter channel.

tostring

the phone number or e-mail address to whom this message was sent. It depends on the value of the parameter channel.

type'inbound' | 'outbound'

Indicates if a message was sent from Luma to an external person, or the other way around.

voiceAnsweredBy

Indicates what this is about. Depending on this value, you also know what the parameter refId refers to.

reminder (refId will be the ID of a Reminder)
referral-reminder (refId will be the ID of a Reminder)
feedback-reminder (refId will be the ID of a Reminder)
followup (refId will be the ID of a Reminder)
outbound-referral-reminder (refId will be the ID of a Reminder)
form-reminder (refId will be the ID of a Reminder)
reschedule (refId will be the ID of a Reminder)
waitlist (refId will be the ID of a Waitlist)
appointment-offer (refId will be the ID of a Offer)
chat-notification (refId will be the ID of a Message)
pin-verification (refId will be the ID of a Message)
chat (refId will be the ID of a ChatActivity)
chat-audit (refId will be the ID of a ChatActivity)
chat-audit-tz (refId will be the ID of a ChatActivity)
feedback (refId will be the ID of a Feedback request)
waitlist-offer (refId will be the ID of an Appointment)
referral-followup (refId will be the ID of a Referral)
outbound-referral-outreach (refId will be the ID of a Referral)
referral-redirect (refId will be the ID of a Referral)
broadcast (refId will be the ID of a Broadcast)
generic (refId will refer to the same object of the previous message to this same patient)
stop (refId will refer to the same object of the previous message to this same patient)
bot:followup (refId will be the ID of a Patient)
telehealth (refId will be the ID of a Telehealth object)
waiting-room-patient (refId will be the ID of a WaitingRoomPatient object)

refIdstring

The ID of the object referenced by the ref parameter.

patientMessageTemplatestring

The ID of a Hub Message Template (or PatientMessageTemplate). These are custom messages, created by users, to make their typing experience easier.

outboundMessagestring

This field is only present on a patient's reply (aka messages whose type are inbound) so as to link it to the original outbound message that was sent to them.

The deliverability status, provided by Luma's external vendors. Messages are initially created as sent, and later updated to some other status.

Sent = vendor has acknowledged receipt of request
Pending = vendor has sent non-terminating status update
Delivered = vendor has confirmed a delivered message
Undelivered = vendor has confirmed an undelivered message
Opened = vendor has confirmed an opened message
Skipped = system skipped sending the message

skippedStatusReasonstring

This field is only present on messages whose status is skipped. It contains the reason why Luma decided to skip sending the message out.

Language

The channel used to send this message. On our RESTful API, you may search for multiple channels, but only POST chat messages. Two of them deserve an explanation:

chat will check the recipient's contact and pick the channel automatically.
inapp are meant for internal messages, when a staff user @mentions another staff user on Hub. The mentioned person only gets a notification on their browser window, by fetching from the notifications API.

shouldForceContactWithNotifyToboolean

textstring

The content of the message. If the channel was chat, then the text was manually provided when the message was created. For all other channels, the key was used to fetch a messageTemplate and determine the text based on that template.

classification'positive' | 'negative' | 'irregular' | 'recognized-keywords' | 'unclassified'

The classification of patient replies (inbound messages) interpreted by our NLP (Natural Language Processing) service.

positive indicates a yes-type answer (e.g. "sounds good", "yes", or "ok")
negative indicates a no-type answer (e.g. "no way", "negative", "no good")
irregular indicates classification attempt was not able to classify the text as positive or negative
recognized-keywords indicates that an expected keyword was identified (e.g. "waitlist")
unclassified indicates no classification attempted - yet

secureboolean

automatedboolean

Indicates if a message was created by users (chat) or by the system (reminders, recalls, etc).

visibility'public' | 'private' | 'internal'

Helps determine where a certain message should be displayed.

public = manual and automated messages sent to patients, visible to patients logged into our patient web app;
private = automated messages sent to staff, only visible to one recipient staff user;
internal = manual messages sent from staff to staff, visible to both staff users involved in a conversation, whenever one @mentined the other, both logged into our internal web app, and usually on Hub rather than any notification areas.

filestring

The ID of a FileUpload, in case this message has any attachment, sent via the FileUpload RESTful API.

terminatingStateAtstring date-time

The time that we recognize a terminal state of a message updated based on the vendor status callbacks.

recipientstring

The ID of the User receiving the message. Usually, for messages type outbound, the recipient is the ID of a patient.

recipientType'doctor' | 'staff' | 'patient'

The type of the user in the field recipient

appointmentstring

ID of Appointment

providerstring

ID of Provider

appointmentTypestring

ID of AppointmentType

followupstring

ID of Followup or Custom Action

recallstring

ID of Recall

referralstring

ID of Referral

messageFailurestring

ID of MessageFailure