Claude Code for Node APIs: Install, Cut Token Costs, Auto-Generate Postman Tests

If you've only used Claude Code to scaffold new files, you're leaving most of its value on the table. The bigger win is running it against a codebase you already have — an Express API with real models, real routes, and real technical debt — and using it to enhance, review, refactor, document, and test that code without blowing through your token budget. This post walks through all of that using a small Express + MongoDB Task API as the working example, with a companion repo at claude-code-express-api-toolkit you can clone and run every prompt below against.

By the end, you'll have Claude Code installed and authenticated, a CLAUDE.md and a cost-cutting hook wired into a real project, a repeatable workflow for enhancements/reviews/refactors on existing code, and a Postman collection generated straight from your routes.

Prerequisites

• macOS 13+, Windows 10 1809+, Ubuntu 20.04+, Debian 10+, or Alpine 3.19+, with 4 GB+ RAM
• A Claude Pro, Max, Team, Enterprise, or Console account (Claude Code isn't included on the free claude.ai plan)
• Node.js 18+ if you want to run the sample API (Node 22+ only if you install Claude Code itself via npm)
• Git, and ideally the gh CLI authenticated for your GitHub account
• A local or hosted MongoDB instance for the sample project

1. Install and run Claude Code

Claude Code ships a native installer for macOS, Linux, and WSL, plus PowerShell/CMD installers for native Windows. This is the recommended path — it auto-updates in the background.

# macOS, Linux, WSL
curl -fsSL https://claude.ai/install.sh | bash

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

Prefer Homebrew, WinGet, apt, dnf, or npm instead? They all work, but only the native installer and npm ship the same auto-updating binary — Homebrew, WinGet, and Linux package managers need manual upgrades:

brew install --cask claude-code        # Homebrew (stable channel)
npm install -g @anthropic-ai/claude-code   # npm — needs Node.js 22+

Verify the install, then authenticate:

claude --version
claude doctor    # deeper health check of your install and config

cd your-project
claude           # follow the browser OAuth prompt on first run

Once you're in, ask Claude something about the project to confirm it's reading your files:

give me an overview of this codebase

If you're following along with the sample repo:

git clone https://github.com/deepakrout/claude-code-express-api-toolkit.git
cd claude-code-express-api-toolkit
npm install
cp .env.example .env
npm run dev
claude

2. Get the best out of it: setup, prompting, and control

Three things separate a frustrating Claude Code session from a great one: a good CLAUDE.md, specific prompts, and knowing when to plan before you let it touch code.

Write a CLAUDE.md. This file loads into every session automatically. Run /init to generate a starting point from your project structure, then trim it — anything Claude could figure out by reading the code doesn't belong here. The sample repo's .claude/CLAUDE.md is a good template:

# Project: Task API (Express + Mongoose)

## Commands
- `npm run dev` - start with auto-reload
- `npm test` - run the node:test suite

## Code style
- Controllers stay thin: validation lives in the model
- Every controller must call next(err) on failure

## Workflow
- Run npm test before considering a task done
- Don't add new npm dependencies without asking first

Keep it under roughly 200 lines. A bloated CLAUDE.md causes Claude to ignore parts of it — for every line, ask "would removing this cause a mistake?" If not, cut it.

Be specific. Vague prompts trigger broad, expensive scanning. Compare "add tests for foo.py" to "write a test for foo.py covering the edge case where the user is logged out, avoid mocks." The second gives Claude a scope and a constraint instead of an invitation to explore everything.

Plan before you code, for anything non-trivial. Press Shift+Tab (or start with claude --permission-mode plan) to enter plan mode: Claude reads and proposes but doesn't edit until you approve. Skip this for a one-line fix; use it for anything touching multiple files or unfamiliar code.

claude (plan mode)
> read src/controllers and src/models and figure out how validation
  currently works, then propose a plan to move it into the schema

Give Claude something to verify against. "Improve the login flow" leaves Claude guessing when it's done. "Write a failing test that reproduces the bug, then fix it until the test passes" gives it a stop condition it can check itself, so you're not the only verification loop in the room.

3. Working against code that already exists

This is where Claude Code earns its keep — not greenfield scaffolding, but enhancements, reviews, and refactors on a codebase with history and constraints.

Enhancements. Point at the existing pattern, not just the goal:

add a "tags" field (array of strings, max 5) to the Task model, expose
it in the create/update controllers, and support filtering tasks by tag
via a ?tag= query param. Follow the existing filter pattern used for
status and priority in taskController.js

Code review. Ask for findings before asking for fixes — a review-then-fix pass catches more than "just fix it" does, and you get to see the reasoning:

review src/controllers/taskController.js for missing input validation,
unhandled edge cases, and inconsistent error responses. Don't fix
anything yet, just report findings.

For a second opinion that isn't biased by having just written the code, run the bundled review skill in a fresh subagent, or open a second session as a dedicated reviewer against the diff — Anthropic's own best-practices guidance calls this the Writer/Reviewer pattern.

Refactoring. Refactors are where "verify, don't trust" matters most. Ask for behavior-preserving changes explicitly, and always close the loop with a test run:

refactor taskController.js so validation lives in the Task schema
instead of the controller, keep behavior identical, then run npm test

Do refactors in small, testable increments rather than one sweeping pass — it's easier to Esc and course-correct three lines in than to unwind a 40-file rewrite.

4. Keep token usage — and your bill — under control

Claude Code bills by API token consumption, and Anthropic's own numbers put typical enterprise usage around $13/developer/day, with 90% of users staying under $30/day. Context size is the main lever: the more Claude reads, the more you pay, and performance degrades as the context window fills regardless of cost. A few concrete habits:

• /clear between unrelated tasks. Stale context from a previous task wastes tokens on every message that follows it. Rename first with /rename if you'll want to /resume it later.
• Delegate exploration to subagents. use a subagent to investigate how token refresh works in our auth code keeps the file reads out of your main context — only the summary comes back.
• Move detailed instructions out of CLAUDE.md and into skills. CLAUDE.md loads on every single session start, whether it's relevant or not. Skills load on demand.
• Filter noisy tool output with a hook. A PreToolUse hook can grep a 10,000-line test log down to just the failures before Claude ever sees it. The sample repo ships exactly this hook:

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": ".claude/hooks/filter-test-output.sh" }]
      }
    ]
  }
}

# .claude/hooks/filter-test-output.sh
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command')
if [[ "$cmd" =~ ^(npm test|node --test) ]]; then
  filtered_cmd="$cmd 2>&1 | grep -A 5 -E '(FAIL|not ok|Error)' | head -100"
  echo "{\"hookSpecificOutput\":{\"hookEventName\":\"PreToolUse\",\"permissionDecision\":\"allow\",\"updatedInput\":{\"command\":\"$filtered_cmd\"}}}"
else
  echo "{}"
fi

• Prefer CLI tools over MCP servers when both exist. gh, aws, and gcloud don't add a per-tool listing to your context the way an MCP server's tool definitions can. Run /mcp and disable servers you're not actively using.
• Match the model to the task. Sonnet handles the large majority of coding work well and costs less than Opus — save Opus for genuinely hard architectural calls. Switch mid-session with /model.
• Check /usage. It shows session token cost directly, plus a breakdown by skill, subagent, and MCP server on paid plans — useful for spotting which part of your setup is actually expensive.

5. Document code you've already written

Claude Code can read existing functions and generate documentation that actually matches the code, rather than drifting docs someone wrote once and never updated:

find functions without proper JSDoc comments in src/controllers, add
JSDoc to each one, then generate docs/API.md summarizing every endpoint,
its request body, and its response shape

Two things make this reliable rather than approximate: ask Claude to read the actual route and controller files (not describe them from memory), and specify the doc style you want (JSDoc, docstrings, an OpenAPI-style markdown table). The sample repo's docs/API.md is exactly this output for the Task API — regenerate it any time the routes change by re-running the same prompt.

6. Generate a Postman collection from your API code

If you've got an Express (or any HTTP framework) app, Claude Code can read the routes and controllers and produce a working Postman collection — including request bodies and basic test assertions — without you hand-writing a single JSON block:

read src/routes/taskRoutes.js and src/controllers/taskController.js and
generate a Postman v2.1 collection at postman/task-api.postman_collection.json
covering every endpoint, with example request bodies for create/update,
a {{baseUrl}} collection variable, and a pm.test() assertion per request

What makes the output usable instead of just plausible-looking JSON:

• Point Claude at the actual route file and controller, not a description of the API — it can then infer required fields from your Mongoose schema instead of guessing
• Ask explicitly for a {{baseUrl}} variable so the collection isn't hardcoded to localhost:3000
• Ask for at least one assertion per request (pm.test(...)) so importing the collection gives you a pass/fail signal, not just raw responses
• Re-run the same prompt after route changes — regenerating is cheaper and more accurate than hand-editing stale JSON

The sample repo's postman/task-api.postman_collection.json covers all five Task endpoints plus a 404 case, each with its own test script. Import it into Postman, set baseUrl if needed, and run the collection.

Reference: cost-reduction levers at a glance

What's next

• Wire the review skill or a second Claude session into your PR workflow as a standing Writer/Reviewer pattern
• Add a project-specific skill (.claude/skills/) that encodes your team's API conventions so Claude stops re-deriving them every session
• Set up a PreToolUse hook that blocks writes to your migrations folder, so a wrong-direction refactor can't touch schema history
• Try claude -p "prompt" --output-format json in a pre-commit hook or CI step to run a lint/review pass automatically on every push

Further reading

• Claude Code setup and installation — full platform matrix and advanced install options
• Best practices for Claude Code — the source for most of the prompting patterns above
• Common workflows — recipes for debugging, refactoring, and PRs
• Manage costs effectively — the full token-reduction and spend-tracking reference
• Hooks guide — build your own PreToolUse/PostToolUse automation
• MCP overview — connect Claude Code to external tools and services

Every prompt in this post, plus the CLAUDE.md, hook, and generated Postman collection it produced, lives in the companion repo: github.com/deepakrout/claude-code-express-api-toolkit. Clone it, run claude from the root, and work through the six sections against real code instead of a toy example.