Claude API Chatbot for Ecommerce Websites: A Build Guide

If you're building a Claude API chatbot for an ecommerce website, the core job is answering three kinds of questions well: product questions ("does this fit a 13-inch laptop?"), order/account questions ("where's my package?"), and sales-adjacent questions ("what should I get for a runner?"). Claude is strong at all three because it handles long context (full product catalogs, policy docs), follows tool-use instructions to call your order API, and produces natural, on-brand responses instead of canned FAQ text.

This article walks through the architecture, what to feed the model, how to wire up order lookups with tool use, and how to keep latency low with streaming — plus how a service like SubToAPI fits in if you want this running behind a normal HTTPS API key instead of managing SDK auth yourself.

What an Ecommerce Chatbot Actually Needs

Before writing code, define the chatbot's job narrowly. Most ecommerce bots fail not because the model is weak, but because scope is unclear. A solid v1 covers:

• Product questions — sizing, materials, compatibility, shipping times
• Order status — lookup by order ID or email, pulled from your order system, not the model's memory
• Returns/policy — answered from your actual return policy text, not guessed
• Light recommendations — "show me something similar but cheaper"

Anything requiring a real transaction (processing a refund, changing an address) should be a tool call that hits your backend, confirmed by a human-readable summary before it executes.

Architecture Overview

A production setup looks like this:

1. Frontend chat widget sends the user message to your server.
2. Your server attaches system instructions, recent order/product context, and conversation history.
3. The request goes to Claude (directly via Anthropic, or through SubToAPI's /v1/messages endpoint using a sub_live_... key).
4. If Claude decides it needs order data, it calls a tool; your server executes that against your order database and returns the result.
5. The final answer streams back to the widget.

Keep order lookups, inventory checks, and pricing out of the prompt as static text — use tool use so the model always gets live data, not stale catalog snippets baked into a system prompt months ago.

Setting Up the System Prompt

The system prompt should define scope, tone, and escalation rules explicitly:

You are the support assistant for Acme Outdoor Gear.
- Answer product and order questions using the tools provided.
- Never invent order statuses, tracking numbers, or stock levels.
- If a question requires a refund or address change, call the
  appropriate tool and summarize the result for the customer.
- If you can't help, say so and offer a link to human support.
- Keep responses under 4 sentences unless the user asks for detail.

This single block eliminates most of the "chatbot made something up" complaints that give AI support bots a bad name.

Order Lookup via Tool Use

Here's a minimal tool definition for order status, sent with the request:

{
  "name": "get_order_status",
  "description": "Look up the status of an order by order ID or customer email",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": { "type": "string" },
      "email": { "type": "string" }
    }
  }
}

When Claude calls this tool, your server runs the real lookup and sends the result back as a tool result message. Claude never sees your database directly — it just gets the JSON you return. This is the same pattern covered in SubToAPI's tool use docs, and it's the mechanism that keeps answers grounded in real data instead of hallucinated tracking numbers.

Example Request

If you're calling Claude through SubToAPI, the request shape mirrors the standard Messages API — same JSON, same streaming, just a different key and base URL:

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-sonnet-4-5",
    max_tokens: 500,
    system: "You are the support assistant for Acme Outdoor Gear...",
    messages: [
      { role: "user", content: "Where is my order #10234?" }
    ],
    tools: [ /* get_order_status, search_products, etc. */ ]
  })
});

Because SubToAPI issues application keys (sub_live_...) per project, you can give the ecommerce chatbot its own key, separate from internal tooling, and track its usage independently in the dashboard. See /docs/quickstart for the full setup and /docs/messages for the request/response format.

Streaming for a Responsive Widget

Ecommerce chat widgets feel sluggish if the customer stares at a blank bubble for 2–3 seconds. Streaming fixes this by rendering tokens as they arrive:

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-sonnet-4-5",
    max_tokens: 500,
    stream: true,
    messages: [{ role: "user", content: "Do you have this in size M?" }]
  })
});

for await (const chunk of res.body) {
  // append text deltas to the chat UI as they arrive
}

Full event format is in /docs/streaming. Streaming alone often fixes the "feels slow" complaint more than switching models does.

Feeding Product Data Without Bloating Every Request

Don't paste your entire catalog into every system prompt — it's slow and expensive. Instead:

• Use a lightweight retrieval step: search your product database for relevant items based on the user's message, then inject only the top 3–5 matches into context.
• Keep static policy text (shipping, returns) in the system prompt since it rarely changes and is small.
• Cache conversation history server-side; send only the last few turns plus a summary of older ones for long sessions.

This keeps token usage predictable, which matters once you're running a chatbot at real traffic volumes — check /pricing if you want a flat per-seat cost instead of metering every request separately.

Handling Escalation Gracefully

Design an explicit exit ramp: after 2 failed attempts to resolve a question, or whenever the user asks for a human, the bot should say so clearly and hand off a transcript rather than looping. This single rule prevents most of the frustration associated with ecommerce bots.

Getting Started

If you already have Claude API access through your Anthropic account, you can wrap it with SubToAPI to get a stable HTTPS endpoint, per-project API keys, and usage dashboards for the chatbot without extra infrastructure. Start at /signup with the free trial, or go straight to /docs/quickstart to see the request format before committing.

FAQ

Does Claude need to be fine-tuned for ecommerce use? No. Fine-tuning is rarely necessary — a clear system prompt, tool use for live order/inventory data, and a focused scope get you most of the way there.

How do I stop the chatbot from inventing order statuses or stock numbers? Never put that data in the prompt as static text. Require Claude to call a tool for anything that changes (orders, stock, pricing) and explicitly instruct it not to answer those categories without a tool result.

Can I run this without managing Anthropic SDK auth directly? Yes — SubToAPI issues an HTTPS API key you call directly, with the same request/response shape as the standard Messages API, so you don't need to manage provider-specific auth in your app.