Claude API Integration for Internal Dashboards

What "Claude API integration for an internal dashboard" actually means

Most internal dashboards — admin panels, support consoles, ops tools, data review screens — need an AI feature at some point: summarizing a ticket, generating a report, answering a question about a record on screen, or drafting a reply for a human to approve. Integrating the Claude API into that dashboard means adding a server-side call to Claude, streaming or returning the response into your existing UI, and doing it in a way that doesn't leak API keys to the browser or break when five people on your team hit it at once.

This is different from building a public-facing AI product. Internal dashboards usually have a small, known user base (your team), lower traffic, but a real need for access control, usage visibility, and a setup that doesn't require a backend engineer every time someone wants to add a new feature. Below is a concrete path to get Claude running inside an internal tool, plus the decisions that actually matter.

Decide where the Claude call lives

There are three places you can put the call:

1. Directly from the frontend — never do this. It exposes your API key in the browser bundle.
2. A thin backend route in your existing app — the most common pattern. Your dashboard already has a backend (Express, Rails, Django, whatever); add one route that calls Claude and returns the result.
3. A dedicated internal service — makes sense once multiple internal tools need Claude access and you want one place to manage keys, logs, and rate limits.

For most teams, option 2 is enough to start, and you can refactor to option 3 later without changing how the frontend talks to your backend.

A minimal backend route

Here's a plain Node/Express route that takes a request from the dashboard, calls Claude, and returns the result as JSON:

app.post('/internal/ai/summarize', async (req, res) => {
  const { text } = req.body;

  const response = 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: 400,
      messages: [
        { role: 'user', content: `Summarize this ticket in 3 bullet points:\n\n${text}` }
      ]
    })
  });

  const data = await response.json();
  res.json({ summary: data.content[0].text });
});

The frontend just calls /internal/ai/summarize like any other internal API endpoint. No Claude-specific logic leaks into your React/Vue/whatever component beyond rendering the result.

If you're starting from scratch, the /docs/quickstart walks through the request/response shape in more detail, and /docs/messages covers the full parameter set (system prompts, max tokens, stop sequences).

Streaming into the UI without rebuilding your frontend

For dashboards where the AI output is longer than a sentence (report generation, drafting a response, multi-paragraph analysis), streaming makes the tool feel responsive instead of frozen for 8 seconds. You don't need WebSockets for this — Server-Sent Events over your existing HTTP route work fine for an internal tool with a handful of concurrent users:

app.post('/internal/ai/draft-reply', async (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');

  const upstream = 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: 800,
      stream: true,
      messages: [{ role: 'user', content: req.body.prompt }]
    })
  });

  for await (const chunk of upstream.body) {
    res.write(chunk);
  }
  res.end();
});

Full streaming setup, including how to parse the event types, is in /docs/streaming.

Access control: who on your team can trigger Claude calls

Internal tools have a specific problem public apps don't: everyone on the team technically has access to the dashboard, but not everyone should be able to burn through your AI budget or trigger expensive calls. Two practical options:

• Role-gate the route — only admin or support-lead roles can hit /internal/ai/* endpoints. This is usually a few lines in your existing auth middleware.
• Use per-feature API keys — if different internal tools (support dashboard, sales dashboard, ops dashboard) each call Claude, give each one its own key so you can see usage and revoke access independently without redeploying code.

SubToAPI issues separate sub_live_... keys per application from one dashboard, which maps directly to this pattern: one key for the support dashboard, one for the internal reporting tool, one for the sales console, each with its own usage metadata. If you add a teammate who needs to manage keys without touching production credentials, Team and Scale plans add seats for exactly that — see /pricing.

Adding tool use for data lookups

A common internal-dashboard pattern is letting Claude pull live data instead of just summarizing text you pasted in — "look up this customer's last 5 orders and draft a response." That's a tool-use call where you define a function like get_customer_orders, Claude decides when to call it, your backend executes it against your database, and you return the result back to Claude for the final answer. The schema and request flow for this is documented in /docs/tools — it's the same /v1/messages endpoint with a tools array added, not a separate API.

Monitoring usage before it surprises you

Because internal dashboards tend to grow organically — someone adds "summarize this" to one screen, then another team copies the pattern — usage can climb without anyone tracking it. Before wiring Claude into more than one internal tool, decide where you'll check usage: per-key token counts, per-route logging, or a monthly export. SubToAPI's dashboard shows usage per key out of the box, which is enough for most internal tooling without building your own analytics layer.

Getting started

If you don't already have Claude access wired up at the infrastructure level, the fastest path is:

1. Sign up and generate a key at /signup (free trial included).
2. Add one backend route that calls /v1/messages with that key.
3. Wire it to the smallest, highest-value screen first — a summarize button, a draft-reply button — before expanding to streaming or tool use.

Questions

Do I need a separate backend service to add Claude to an internal dashboard? No. A single route in your existing backend is enough to start. Only split it into a dedicated service once multiple internal tools need Claude and you want centralized key management.

How do I stream Claude's response into a dashboard without WebSockets? Server-Sent Events over a standard HTTP POST route work well for internal tools with low concurrent usage — forward the upstream stream chunks directly to the response. See /docs/streaming for the event format.

How should I control who can trigger AI calls in an internal tool? Gate the route by role in your existing auth layer, and use separate API keys per internal application so you can track and revoke usage independently without affecting other tools.