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:
- Access to the REST API quickstart
- Access to the RTM API quickstart
- API credentials stored securely on your backend
- A Crisp API library or your own HTTP/WebSocket implementation
Understand the backend messaging flow
A simple backend bot usually follows this flow:
- Your backend connects to the RTM API and listens for visitor messages.
- The RTM event includes the website_id and session_id needed to reply.
- Your backend checks the message content.
- 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
Updated on: 03/05/2026
Thank you!