ELM HQ logo ELM HQ
ELM infrastructure and server environment
Developers

ELM chat, for any public website.

A public ELM HQ chat API can let a website show “chat with us” while ELM HQ handles identity, chat creation, routing, message delivery, and account creation on the server side.

One script. ELM handles the rest.

A website can add the hosted widget script and set the business PIN it wants visitors to contact. The visitor can send the first message directly from the website. For ELM HQ support, the destination PIN is 02B452C7.

<script
  src="https://www.elm-hq.com/assets/js/elm-chat-widget.js?v=20260920-responsive-contact2"
  data-business-pin="02B452C7"
  data-title="Chat with ELM HQ"
  data-callback-email="support@elm-hq.com"
  data-primary="#23c7ff"
  data-accent="#7f5cff"
  async></script>

The customer site can choose button text, colours and its callback email. After the visitor's first message, the widget offers a compact contact-back form. The conversation keeps receiving replies while minimized, with an unread count and optional browser alerts. The hosted ELM flow still owns conversation state, delivery and support routing.

Base URL: https://www.elm-hq.com/api/v1

Hosted session start

POST /api/v1/chat/sessions creates a server-owned chat session for a business PIN.

Website message

POST /api/v1/chat/website-messages sends the first visitor message from the website.

Identity handoff

GET /api/v1/identity/start signs a visitor in or creates an ELM ID before chat continues.

Business routing

GET /api/v1/businesses/{pin}/chat resolves the public business support destination.

Webhooks

POST /api/v1/webhooks lets approved business systems receive events without owning messages.

Send the first message from the website.

POST /api/v1/chat/website-messages
Content-Type: application/json

{
  "businessPin": "02B452C7",
  "visitorId": "wv_browser_generated_id",
  "conversationId": "web_returned_after_first_message",
  "message": "Hi, I need help with my account.",
  "visitor": {
    "name": "Optional visitor name or ELM ID"
  },
  "source": {
    "type": "website",
    "url": "https://example.com/support",
    "title": "Example support page"
  }
}
{
  "messageId": "elm_msg_...",
  "conversationId": "web_4f2d9a6c8b1e0d5f3a7c9b2e",
  "visitorId": "wv_browser_generated_id",
  "businessPin": "02B452C7",
  "status": "received",
  "deepLink": "elm://chat?conversation=web_4f2d9a6c8b1e0d5f3a7c9b2e"
}

The public site keeps a browser visitor ID and reuses the returned conversation ID on later messages. ELM HQ can then send through Bob while still separating each website visitor into their own support session.

The user's website should not become the messenger.

Public websites should not have to store chat content, create ELM accounts, run identity flows, or manage delivery. They should only identify the business destination, send visitor messages to ELM HQ, and optionally style the visible button.

The ELM HQ service should own session tokens, rate limits, abuse checks, ELM ID creation, app deep links, encrypted message handling, and routing to the correct business inbox.

Brandable without giving away the platform.

Public options should include businessPin, title, buttonText, position, primary, accent, and mode. The visual shell can match a customer's website, but the active chat, account creation, and privacy model remain ELM.

window.ElmChatWidget = {
  businessPin: "02B452C7",
  title: "Chat with ELM HQ",
  buttonText: "Chat with us",
  position: "right",
  primary: "#23c7ff",
  accent: "#7f5cff",
  mode: "hosted"
};

A public chat button with ELM HQ doing the serious work behind it.