Claude Integration Examples for Developers

When developers search for "Claude integration examples," they're usually not looking for a marketing overview of what Claude can do in the abstract. They want working patterns: how to wire Claude into a support queue, a CI pipeline, a document workflow, or a product feature, with actual request/response shapes and error handling considerations.

This article covers six integration patterns that show up repeatedly in production systems, with code you can adapt. Each one focuses on the plumbing — auth, request structure, streaming, tool calls — rather than prompt theory.

1. Customer support triage

A common first integration is routing incoming support tickets: classify urgency, extract the customer's intent, and draft a first-pass reply for a human to approve.

async function triageTicket(ticketText) {
  const res = await fetch("https://api.example.com/v1/messages", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model: "claude-3-5-sonnet",
      max_tokens: 500,
      messages: [{
        role: "user",
        content: `Classify urgency (low/medium/high), extract intent in one sentence, and draft a reply:\n\n${ticketText}`
      }]
    })
  });
  return res.json();
}

The integration work here isn't the prompt — it's making this call reliable at scale: retries on 429s, timeouts, and a fallback path when the model call fails so tickets don't get stuck.

2. Automated code review comments

Attaching Claude to a CI job that runs on pull requests is a popular pattern for catching obvious issues before a human reviewer looks at the diff.

curl https://api.example.com/v1/messages \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-3-5-sonnet",
    "max_tokens": 800,
    "messages": [{
      "role": "user",
      "content": "Review this diff for bugs, security issues, and missing tests. Only flag real problems: '"$DIFF"'"
    }]
  }'

The output gets posted as a PR comment via your CI system's API (GitHub Actions, GitLab CI, etc.). The integration surface is small: one API call in, one comment out. The reliability requirements are what make it non-trivial — you need consistent latency so it doesn't block merges, and you need the response format constrained enough to parse into comment threads.

3. Document and data extraction

Turning unstructured documents (invoices, contracts, resumes) into structured JSON is one of the highest-value Claude integrations because it replaces brittle regex or OCR-plus-rules pipelines.

const response = await fetch("https://api.example.com/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${API_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-3-5-sonnet",
    max_tokens: 1000,
    messages: [{
      role: "user",
      content: `Extract vendor name, invoice number, total, and due date as JSON. Text:\n\n${invoiceText}`
    }]
  })
});

For anything beyond a prototype, this pattern benefits from tool use (function calling), where you define a schema and Claude returns arguments matching it instead of free-form text you have to parse. If you're building this on SubToAPI, the tool-calling behavior works the same way as the underlying Claude API — see /docs/tools for the request shape and response format.

4. Internal knowledge base Q&A

Teams commonly integrate Claude with an internal wiki or docs set by retrieving relevant chunks (via embeddings or search) and passing them as context alongside the user's question:

const context = await searchDocs(userQuestion); // your retrieval logic
const messages = [{
  role: "user",
  content: `Answer using only this context. If the answer isn't here, say so.\n\nContext:\n${context}\n\nQuestion: ${userQuestion}`
}];

This is a retrieval-augmented generation (RAG) pattern, and the Claude-specific part is small — one messages call. Most of the engineering effort goes into the retrieval step, not the model call itself.

5. Structured output with tool use

When you need guaranteed structure — not just "usually valid JSON" — defining a tool schema is the more reliable integration pattern than asking the model to format text:

{
  "model": "claude-3-5-sonnet",
  "max_tokens": 500,
  "tools": [{
    "name": "extract_ticket",
    "description": "Extract structured ticket data",
    "input_schema": {
      "type": "object",
      "properties": {
        "urgency": { "type": "string", "enum": ["low", "medium", "high"] },
        "category": { "type": "string" },
        "summary": { "type": "string" }
      },
      "required": ["urgency", "category", "summary"]
    }
  }],
  "messages": [{ "role": "user", "content": "..." }]
}

This example works the same whether you're calling Claude directly or through a gateway — the important part is that your application code parses tool_use blocks from the response instead of scraping text.

6. Streaming chat interfaces

For any user-facing chat feature, streaming tokens as they're generated matters for perceived latency. A minimal server-sent-events consumer looks like:

const res = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${SUBTOAPI_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-3-5-sonnet",
    max_tokens: 1024,
    stream: true,
    messages: [{ role: "user", content: userMessage }]
  })
});

const reader = res.body.getReader();
// read chunks, parse SSE events, append text deltas to the UI

SubToAPI implements the same streaming and messages format as the underlying Claude API, so existing integration code generally ports over with just a base URL and key change — see /docs/streaming and /docs/messages for the exact event shapes.

Choosing how to connect Claude to your product

All six examples above use the same underlying shape: a messages endpoint, optional tool schemas, optional streaming. Where teams diverge is in how they manage access — individual API keys, usage tracking across features, and team billing.

SubToAPI turns an existing Claude subscription into an HTTPS API with application-scoped keys (sub_live_...), so different features (support bot, CI job, internal search) can each get their own key with separate usage visibility, without sharing one raw credential across a codebase. Plans start at €9/month for solo use, with per-seat pricing for teams — see /pricing. Setup takes about the time it takes to read /docs/quickstart, and there's a free trial at /signup if you want to test one of the patterns above before committing.

questions

Do these examples require a specific Claude plan or API tier? No — they use the standard messages endpoint with optional tools and streaming, which works with any valid API access, including keys issued through /docs/quickstart.

Which integration pattern should I build first? Start with whichever has the clearest input/output boundary — document extraction or code review comments are usually easier to ship than open-ended chat, since success is easier to measure.

Is tool use necessary for structured output, or is prompting enough? Prompting can produce JSON-like text, but tool use (see /docs/tools) enforces a schema, which matters once you're parsing responses in production rather than eyeballing them in a demo.