Articles on: Developers

How to send messages from your backend

Learn how to send Crisp messages from your own backend using the REST API and RTM API together.


Backend messaging is useful when you build bots, automations, or internal systems that need to reply inside Crisp conversations. In most cases, your backend listens to live events with the RTM API, then sends replies with the REST API.



Before you start


Your backend needs to be connected to the Crisp APIs before it can listen to messages or send replies.


You will need:


API credentials must stay server-side. Do not send messages from frontend code with private API credentials.



Understand the backend messaging flow


A simple backend bot usually follows this flow:


  1. Your backend connects to the RTM API and listens for visitor messages.
  2. The RTM event includes the website_id and session_id needed to reply.
  3. Your backend checks the message content.
  4. If the message matches your automation rule, your backend sends a reply with the REST API.


The example below listens for a visitor message matching Hi and replies with Hello World.



Build a basic Go messaging bot


This example assumes you are using the Crisp Go library and that your backend is connected to both the REST and RTM APIs.


// Listen for sent messages from visitors
client.Events.Listen([]string{"message:send"}, func(reg *crisp.EventsRegister) {
fmt.Print("Now listening for events\n")

reg.On("message:send/text", func(evt crisp.EventsReceiveTextMessage) {
fmt.Print("Got message content:", *evt.Content)

if *evt.Content == "Hi" {
// Build message
message := crisp.ConversationTextMessageNew{
Type: "text",
From: "operator",
Origin: "chat",
Content: "Hello World",
Fingerprint: 0
}

// Message matches "Hi", we can send the reply
_, _, err := client.Website.SendTextMessageInConversation(
*evt.WebsiteID,
*evt.SessionID,
message
)

if err != nil {
fmt.Printf("Error: %s", err)
} else {
fmt.Print("Reply message sent to:", *evt.SessionID)
}
}
})
})



Make the bot production-ready


The example is intentionally simple. Before deploying a real automation, add guardrails so it behaves predictably.


Recommended checks:

  • Conversation scope → only reply to the websites or inboxes your bot should handle
  • Message origin → avoid replying to your own operator messages
  • Error handling → log failed REST calls and retry only when it is safe
  • Rate control → avoid loops and repeated answers for the same visitor input
  • Human handoff → stop the bot when an operator takes over or when escalation is needed


You can inspect available conversation message routes in the REST API reference.


Updated on: 03/05/2026

Was this article helpful?

Share your feedback

Cancel

Thank you!