How Delivery Chat Works

What is Delivery Chat?

Delivery Chat is a multi-tenant customer support chat platform. You add a fully customizable chat widget to your website, your visitors start conversations directly on your site, and your team handles them from a centralized admin dashboard.

Think of it as a support inbox that lives on your website: you control when your team is available, how the widget looks, and who can reply.

Real-World Example: Delivery Chat runs on Delivery Chat

The clearest example is our own setup — we use Delivery Chat to support Delivery Chat. Here is how it fits together:

How the Delivery Chat team uses Delivery Chat

Create an organization

The Delivery Chat team signs up and creates an Organization:

The organization gets its own dashboard subdomain, e.g. deliverychat.deliverychat.online
All applications, team members, and billing live under this single organization
You can start on the Free plan and upgrade as you grow

Create applications for each website

An Application is one chat widget instance, tied to the website domain where it is embedded. The Delivery Chat team runs two:

Landing Page (domain: deliverychat.online) — pre-sales questions, its own colors and greeting
Docs (domain: docs.deliverychat.online) — integration and API help, with the AI Assistant answering from our own docs

Each application has independent settings: widget appearance, business hours, auto-responses, and its own appId. Both are managed from the same organization dashboard.

Add team members

Invite the people who will handle conversations:

Admins configure settings, billing, and applications
Operators pick up conversations from the queue and reply
Roles and permissions are enforced per organization

Embed the widget

Add the widget snippet to each site. The widget is embedded on your own domain (e.g. deliverychat.online) and talks to the Delivery Chat API at api.deliverychat.online. Conversations show up in your dashboard in real time.

Integration Methods

There are three supported ways to integrate Delivery Chat. All of them use the same API base URL, https://api.deliverychat.online/api/v1.

A vanilla JavaScript embed. Drop the snippet on any page — no framework required. It only needs your public appId; no secret key is exposed in the browser.


<script>
  (function(w,d,s){
    w.DeliveryChat=w.DeliveryChat||function(){(w.DeliveryChat.queue=w.DeliveryChat.queue||[]).push(arguments)};
    var js=d.createElement(s);js.async=1;js.src='https://api.deliverychat.online/widget.js';
    d.head.appendChild(js);
  })(window,document,'script');
 
  DeliveryChat('init', { appId: 'YOUR_APP_ID' });
</script>

When to use: Almost always. Quick setup, automatic styling, works on any stack. See Chat Widget Integration.

Option 2: JavaScript SDK (`@deliverychat/sdk`)

An npm package for apps that need programmatic control — opening/closing the widget, listening to events, sending messages, or building a custom UI in headless mode.


import { init, getSdkApi } from "@deliverychat/sdk";
 
init({
  appId: "YOUR_APP_ID",
  apiBaseUrl: "https://api.deliverychat.online",
});
 
const chat = getSdkApi();
chat.on("ready", () => {
  console.log("Widget is ready");
});

When to use: React/Vue/framework apps that need lifecycle control or a fully custom interface. See JavaScript SDK.

Option 3: REST API (server-side)

For custom chat interfaces or server-to-server integrations. Requests are authenticated with an API key (dk_live_... / dk_test_...) plus your X-App-Id, and must be made from your backend — never expose the key in the browser.


# Create a conversation
curl -X POST https://api.deliverychat.online/api/v1/conversations \
  -H "Authorization: Bearer dk_live_your_api_key" \
  -H "X-App-Id: your-app-id" \
  -H "X-Visitor-Id: 550e8400-e29b-41d4-a716-446655440000" \
  -H "Content-Type: application/json" \
  -d '{ "subject": "Hello, I need help with my order" }'
 
# Send a message in that conversation
curl -X POST https://api.deliverychat.online/api/v1/conversations/CONVERSATION_ID/messages \
  -H "Authorization: Bearer dk_live_your_api_key" \
  -H "X-App-Id: your-app-id" \
  -H "X-Visitor-Id: 550e8400-e29b-41d4-a716-446655440000" \
  -H "Content-Type: application/json" \
  -d '{ "content": "Hi! Can you check order #1234?" }'

When to use: Building a completely custom chat UI, or integrating with an existing CRM/support system. See REST API.

What a conversation looks like

A visitor lands on your site

The widget loads using that application's configuration (colors, greeting, business hours)
Outside business hours, your auto-response is shown

The visitor sends the first message

A conversation is created with status pending
It appears in the operator queue in your dashboard in real time

An operator accepts and replies

An operator accepts the conversation (status becomes active)
Messages are delivered live over WebSocket in both directions
When resolved, the conversation is marked closed

The visitor returns later

Their previous conversation is still available
History is retained according to your plan's retention window

Key Concepts

Organizations vs Applications

Organization

Your company account

•Gets one dashboard subdomain (e.g., yourcompany.deliverychat.online)
•Contains one or more applications
•Owns team members, billing, and API keys
•Data is isolated from every other organization

Application

A single chat widget instance

•Has its own website domain (where the widget is embedded)
•Has its own appId and independent configuration
•Can differ from other apps in the same organization
•Public per-visitor rate limits apply to its widget/REST traffic

Why this matters: One organization can run several widgets — a landing page, a docs site, different products or regions — each configured independently but managed from a single dashboard.

Configuration Per Application

Each application can have completely different settings:

Widget Appearance:

✓
Colors- primary, background, text
✓
Logo
✓
Position- bottom-right or bottom-left
✓
Launcher icon- chat, question, or message

Behavior:

✓
Business hours- When operators are available
✓
Auto-responses- Shown outside business hours or as a greeting
✓
AI Assistant- Optional add-on on Premium/Enterprise that answers from your own data

Multi-Tenancy and Rate Limiting

Delivery Chat is multi-tenant: each organization is a tenant with fully isolated data. Rate limiting is applied at two layers:

Rate Limiting:

✓
Public widget & REST API- Limited per visitor and per application (three sliding windows: per-second, per-minute, per-hour). A 429 response carries cause: "per_visitor".
✓
Tenant/admin traffic- Plan-based limits applied per organization across all requests.
✓
Enterprise overrides- Custom limits configurable in Settings → Rate Limits.

See Plans & Pricing for the per-plan numbers and Errors & Rate Limiting for the public API’s per-visitor windows and 429 headers.

Edge Cases and Examples

Example 1: Multiple products under one organization

Scenario:

A company sells two products and wants to support both separately.

Solution:

Create one Organization
Create two Applications, one per product website
Each app has its own domain, branding, and settings
The team manages both from a single dashboard

Example 2: Different business hours per region

Scenario:

A team supports customers across several timezones.

Solution:

Create one Application per region
Set business hours matching each timezone
Write auto-responses in the appropriate language
Assign operators to the regions they cover

Example 3: A fully custom chat interface

Scenario:

An app needs chat that looks native, not like a floating web widget.

Solution:

Use the SDK in headless mode (or the REST + WebSocket API)
Build your own UI while Delivery Chat handles delivery, history, and team management
Conversations still land in the same dashboard

Data Isolation and Security

Each organization’s data is completely isolated:

One tenant can never see another tenant’s conversations
Each application’s data is scoped to its organization
Team members only access the organization they belong to
The widget uses domain-based origin validation, so no secret key is exposed in the browser
API keys and secrets are stored encrypted at rest

Next Steps

Now that you understand how Delivery Chat works:

Get Started — create your organization and first application
Integration Overview — compare the three integration methods
Chat Widget Integration — embed the widget in minutes
Plans & Pricing — pick the plan that fits

How Delivery Chat Works

What is Delivery Chat?

Real-World Example: Delivery Chat runs on Delivery Chat

How the Delivery Chat team uses Delivery Chat

Create an organization

Create applications for each website

Add team members

Embed the widget

Integration Methods

Option 1: Chat Widget (recommended)

Option 2: JavaScript SDK (@deliverychat/sdk)

Option 3: REST API (server-side)

What a conversation looks like

A visitor lands on your site

The visitor sends the first message

An operator accepts and replies

The visitor returns later

Key Concepts

Organizations vs Applications

Organizations vs Applications

Configuration Per Application

Widget Appearance:

Behavior:

Multi-Tenancy and Rate Limiting

Rate Limiting:

Edge Cases and Examples

Scenario:

Solution:

Scenario:

Solution:

Scenario:

Solution:

Data Isolation and Security

Next Steps

Option 2: JavaScript SDK (`@deliverychat/sdk`)