← Blog

Integration With Claude Code: A Practical Guide

2026-09-09 · 5 min read · SubToAPI Team

When developers search for "integration with Claude Code," they usually mean one of two things: how to wire Claude Code's CLI into an existing development workflow (scripts, CI/CD, git hooks), or how to build custom tools and products that use Claude's capabilities programmatically. This article covers both, with concrete examples for each.

Claude Code is Anthropic's command-line agent for coding tasks — it reads your codebase, edits files, runs commands, and can operate in interactive or non-interactive (headless) mode. Integration means connecting that behavior to the rest of your toolchain, rather than only typing into a terminal session by hand.

Headless Mode for Scripting

The core integration primitive is Claude Code's headless/non-interactive mode, which lets you invoke it from a shell script or another program without a live terminal session:

claude -p "Add unit tests for the utils module" --output-format json

This is what makes automation possible. You can pipe input in, capture structured JSON output, and chain Claude Code into larger scripts — for example, a pre-commit hook that asks Claude Code to check for obvious bugs before allowing a commit, or a release script that generates a changelog from recent diffs.

Key things to know when scripting against it:

CI/CD Pipeline Integration

A common integration pattern is running Claude Code as a step in a pipeline: reviewing pull requests, summarizing failing test output, or suggesting fixes for lint errors. A minimal GitHub Actions step might look like:

- name: Claude Code review
  run: |
    claude -p "Review this diff for bugs and style issues: $(git diff origin/main)" \
      --output-format json > review.json

The output can be posted as a PR comment, fed into a bot, or used as a gate that fails the build if certain issues are found. Because headless mode is deterministic in its invocation shape (input in, structured output out), it fits naturally into existing CI tooling without needing a custom integration layer.

Git Hooks and Local Automation

For local workflows, git hooks are a lightweight way to integrate Claude Code without touching CI infrastructure:

#!/bin/sh
# .git/hooks/pre-push
claude -p "Check staged changes for hardcoded secrets or debug statements" \
  --max-turns 3

This keeps the integration entirely local and fast, which matters for hooks that run on every push. The tradeoff is that local hooks don't scale across a team unless everyone has Claude Code installed and configured with valid credentials, which is where teams often start looking at shared, centrally managed access instead of per-developer CLI sessions.

Custom Tools and Agent Workflows

Beyond scripting the existing CLI, some teams build entirely custom tools around Claude's underlying model — internal code review bots, documentation generators, or agents with domain-specific permissions. For this, you're not really "integrating with Claude Code" the CLI anymore; you're integrating with the Claude API directly, using the same model capabilities (tool use, streaming, long context) but through your own interface.

This is where a lot of integration questions actually lead: teams want the reasoning and coding ability that powers Claude Code, but exposed as a plain HTTPS API they can call from a backend service, a Slack bot, or an internal dashboard — without managing separate Anthropic billing, rate limits, or seat provisioning for every developer.

That's the gap SubToAPI fills. It turns an existing Claude subscription into a standard API with sub_live_... application keys, so you can call Claude from any service the same way you'd call any other REST API:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Summarize this PR diff."}]
  }'

Streaming, tool use, and usage metadata all work through the same interface, documented at /docs/messages, /docs/streaming, and /docs/tools. For teams, that means one dashboard for keys and seats instead of each developer running their own local CLI session — useful when the integration you actually need is "Claude in our backend," not "Claude in my terminal."

Choosing the Right Integration Path

A quick way to decide which approach fits:

Most teams end up using more than one of these at once: Claude Code locally for day-to-day coding, a CI step for automated review, and an API integration for anything that needs to run as a backend service rather than a CLI invocation.

questions

Does Claude Code support non-interactive use for automation? Yes. Running claude -p "<prompt>" with --output-format json invokes Claude Code headlessly, making it scriptable in shell scripts, git hooks, and CI pipelines without an interactive session.

Can I integrate Claude's capabilities into a backend service without using the CLI? Yes — that's an API integration rather than a CLI integration. Services like SubToAPI expose Claude as a standard HTTPS API with application keys, streaming, and tool use, so you can call it from any backend without CLI dependencies. See /docs/quickstart.

What's the safest way to run Claude Code in CI? Set --max-turns to bound agentic steps, restrict tool access with --allowedTools, and always capture structured JSON output so pipeline steps downstream can parse results reliably rather than relying on free-text output.

Turn your Claude access into an HTTPS API

SubToAPI gives you application API keys, streaming, tool use and usage insights on top of your existing Claude access — set up in minutes.

Start free  Read the quickstart →