How to Use Claude to Create a Chatbot Demo Fast

Building a chatbot demo with Claude means three things in practice: getting API access, writing a system prompt that shapes the assistant's behavior, and wiring a simple frontend that sends messages and streams responses back. You don't need a framework, a vector database, or a week of setup — a working demo can be running locally in under an hour.

This guide walks through the minimal path: from getting a key to a chat UI that streams tokens, with the option to add tool use if your demo needs to call external functions or APIs.

What "chatbot demo" actually requires

A demo doesn't need production infrastructure, but it does need to feel real. That means:

• A conversational endpoint — something that accepts a message history and returns a reply.
• Streaming — users expect text to appear progressively, not after a 5-second wait.
• Context handling — the demo should remember earlier turns in the same session.
• A system prompt — this defines the persona, tone, and boundaries of your chatbot.

You can build all of this directly against Claude's API, or through a wrapper like SubToAPI that gives you an HTTPS endpoint, an API key, and streaming without managing model versions or auth flows yourself. Either way, the structure of the demo is the same.

Step 1: Get access and a key

If you're using SubToAPI, sign up at /signup and generate a sub_live_... key from the dashboard. It's the fastest route if you want streaming, usage tracking, and tool use available out of the box without separate setup for each. Pricing starts at Solo for €9/month, with Team and Scale plans for multi-seat projects — see /pricing.

Store the key as an environment variable, never hardcode it:

export SUBTOAPI_KEY="sub_live_..."

Step 2: Write the system prompt

The system prompt is what turns "an LLM" into "your chatbot." Be specific about role, tone, and limits. A vague prompt produces a generic assistant; a precise one produces a demo that feels purpose-built.

Example for a support-bot demo:

You are Aria, a support assistant for a project management tool.
Answer only questions about the product. Keep responses under
4 sentences unless the user asks for detail. If you don't know
something, say so and suggest contacting human support.

Step 3: Send your first request

Here's a minimal call using SubToAPI's messages endpoint. The shape mirrors what you'd expect from any Claude-based API — model, messages, and an optional system field.

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-3-5-sonnet",
    "system": "You are Aria, a support assistant for a project management tool.",
    "max_tokens": 300,
    "messages": [
      {"role": "user", "content": "How do I invite a teammate?"}
    ]
  }'

Full request/response details are in /docs/messages, including how to pass multi-turn history and control token limits.

Step 4: Add streaming for a real chat feel

A demo without streaming feels slow even if the total response time is fine, because users see nothing until the whole answer arrives. Streaming fixes this by sending tokens as they're generated.

const res = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-3-5-sonnet",
    system: "You are Aria, a support assistant.",
    max_tokens: 300,
    stream: true,
    messages: [{ role: "user", content: "How do I invite a teammate?" }]
  })
});

const reader = res.body.getReader();
const decoder = new TextDecoder();

while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  process.stdout.write(decoder.decode(value));
}

Details on event formats and reconnect handling are covered in /docs/streaming. This is the single change that makes a demo feel like a real product instead of a script.

Step 5: Build the minimal frontend

You don't need React for a demo — a static HTML page with fetch and a message list is enough:

<div id="chat"></div>
<input id="msg" placeholder="Ask something..." />
<script>
  async function send(text) {
    const chat = document.getElementById("chat");
    chat.innerHTML += `<p><b>You:</b> ${text}</p>`;
    const res = await fetch("/api/chat", {
      method: "POST",
      body: JSON.stringify({ message: text })
    });
    const reply = await res.text();
    chat.innerHTML += `<p><b>Bot:</b> ${reply}</p>`;
  }
</script>

Proxy this through a small backend so your key never reaches the browser. Even for a demo, don't expose credentials client-side.

Step 6: Add tool use if the demo needs it

If your chatbot should look up order status, check inventory, or query a database, use tool calling instead of trying to fake it with prompting. Define a function schema, pass it in the request, and handle the tool call Claude returns before sending the result back for a final reply. This is what separates a "chat toy" demo from one that shows real product value. See /docs/tools for the request format and multi-step tool loop.

Step 7: Keep context across turns

For a multi-turn demo, append each exchange to the messages array and resend the full history with every call — Claude doesn't retain state between requests. Trim older turns once you hit a reasonable token budget so latency and cost stay predictable.

Getting started quickly

If you want to skip the account/auth plumbing entirely, /docs/quickstart walks through getting a working request out in a few minutes using SubToAPI, including how streaming and tool calls plug into the same key.

questions

Do I need a backend server to build a Claude chatbot demo? Yes, at minimum a thin proxy. Calling the API directly from browser JavaScript would expose your key, so route requests through a small server-side handler even for a quick demo.

How do I make the demo remember previous messages? Resend the full conversation history with each request in the messages array. Claude's API is stateless — there's no server-side session, so your app owns the conversation state.

What's the fastest way to add streaming without building it from scratch? Use an API that already exposes a streaming endpoint, like SubToAPI's /v1/messages with stream: true, rather than implementing chunked response handling yourself — see /docs/streaming for the exact event format.