# Build a custom Live Chat interface

Enable the Livechat HTTP API, generate a Line API key, download OpenAPI documentation, and receive conversation messages through a webhook.

## Plan availability

| Feature | Free | Starter | Pro | Enterprise |
| --- | --- | --- | --- | --- |
| Active Lines | 2 | 5 | 15 | Unlimited |
| Active workflows | 3 | 10 | 45 | Unlimited |

Allowances follow the [published Chatigram pricing page](https://chatigram.com/pricing/). Your organization’s Billing & Plans screen confirms its subscription and current usage. Plans can change. Plan information reviewed 2026-11-10.


## Choose the interface you need

Use the [website widget](/channels/livechat/) when you want Chatigram’s ready-made chat interface. Use the Livechat HTTP API when you want your own interface in a website or application while keeping the conversation connected to a Chatigram Live Chat Line and its workflows.

The API is designed for server-to-server requests. Your interface talks to your own server, which holds the Line’s API key and makes authenticated requests to Chatigram. Keep each visitor’s conversation separate in your application.

## Enable API Access

1. Open the intended **Livechat** Line and edit its settings.
2. In **API Access**, turn on **Enable API Access** and save.
3. Return to the Line overview and copy the **API Base URL**.
4. Choose **Generate API Key**. Use **Copy key** and save the key securely before closing the dialog; it is shown only once.
5. Choose **Download OpenAPI Spec**. Import the file into an OpenAPI-compatible viewer or API client to inspect requests, responses, and webhook schemas.

This key grants access to conversations on that Line. Keep it on your server, outside browser code, mobile app bundles, public examples, and AI prompts. **Regenerate** immediately revokes the previous key, so update the applications using it when you replace it.

## Start and continue a conversation

Your application generates a random UUID for each conversation session. The first visitor message creates the conversation automatically. Retain that session ID to continue the same conversation; a new session ID starts a separate one when its first message is sent.

Use your Line’s own **API Base URL** and key. The placeholders below are not a working connection:

```http
POST YOUR_LIVECHAT_API_BASE_URL/conversations/SESSION_UUID/messages
Authorization: Bearer YOUR_LINE_API_KEY
Content-Type: application/json

{
  "type": "TEXT",
  "content": "Hello, I would like help choosing a service."
}
```

To retrieve the session’s messages, oldest first:

```http
GET YOUR_LIVECHAT_API_BASE_URL/conversations/SESSION_UUID/messages
Authorization: Bearer YOUR_LINE_API_KEY
```

A session without messages returns an empty list. Sending a visitor message and receiving an assistant reply are separate events: do not treat the successful send response as the assistant’s completed answer. Enable and assign the intended conversation workflows to the Line.

## Receive messages with a webhook

Subscribe your HTTPS receiver through the API, following the downloaded OpenAPI specification. Webhooks are configured through the API itself; turning on API access does not create a subscription.

| Operation | Path relative to your Line’s API Base URL |
| --- | --- |
| Subscribe or replace the receiver | `PUT /webhook` |
| Remove the receiver | `DELETE /webhook` |

A Line has at most one webhook subscription. Replacing it changes the destination and signing secret, so coordinate with anyone already using that Line’s webhook. Store the returned secret securely and verify the documented delivery signature before processing messages.

The `message.created` event identifies the conversation and includes the message. Use its message ID to avoid displaying a duplicate when a delivery is retried. Use the message’s `sender` and `direction` to distinguish visitor input, workflow responses, and human-agent replies where human support is available.

Return a successful 2xx response after accepting a delivery. Failed deliveries can be retried; see the current specification for delivery behavior. The Line overview’s **Webhook Deliveries** section helps you review delivery results and errors when available.

## Support more than text

Build your interface around the message types described in the specification. A workflow may ask a multiple-choice question, which your interface should render as choices and answer with the corresponding message ID and selected option index. Attachments also have their own payload and download requirements.

Do not assume every message is plain text. Decide how your interface handles unsupported content and connection failures without losing the conversation context.

## Choose the privacy experience

With [Private AI mode](/channels/private-ai/) enabled, conversations are hidden from Inbox and human agents cannot view or reply. Your custom interface must reflect that choice and avoid promising a human response on the same Line.

Private AI mode controls human-agent access through the conversation tools. It does not make a shared Line API key safe to expose: the key still grants conversation access, so your server must control which session each visitor can use.

## Test the complete path

Use fictional messages and a test Line. Check a first message, continuation of the same session, a separate visitor session, a workflow reply, a multiple-choice answer, and a repeated webhook delivery. Verify the selected privacy mode and make sure your interface shows delivery failures clearly.

The Livechat API is separate from the [database REST API](/data/database-api/) and a [workflow HTTP Endpoint](/integrations/http-api/). Use the specification downloaded from the correct Line for this interface.