Backend Endpoint

Backend API Endpoint Generator

Generate production-ready REST or GraphQL endpoints with request validation, error handling, and comprehensive tests.

When to Invoke

Auto-invoke when user mentions:

• "Add endpoint"
• "Create API"
• "New route"
• "Add route"
• "Create API endpoint for [resource]"

What This Does

1. Generates route handler with proper HTTP methods
2. Adds request validation (body, params, query)
3. Implements error handling
4. Creates test file with request/response tests
5. Follows REST/GraphQL conventions
6. Includes authentication middleware (if needed)

Execution Steps

Step 0: Check Existing Patterns (Phase 0)

Before gathering requirements, query the knowledge graph for what we already know about API/endpoint work in this project. Mirrors navigator-research's Phase 0.

PLUGIN_DIR="${CLAUDE_PLUGIN_ROOT:-$(cat "${NAVIGATOR_CONFIG_HOME:-${XDG_CONFIG_HOME:-$HOME/.config}/navigator}/plugin-root" 2>/dev/null)}"
[ -d "$PLUGIN_DIR/skills" ] || PLUGIN_DIR="$HOME/.claude/plugins/marketplaces/navigator-marketplace"
python3 "$PLUGIN_DIR/skills/nav-graph/functions/graph_manager.py" \
  --action query --concept api \
  --graph-path .agent/knowledge/graph.json 2>/dev/null | head -40

Also check authentication, validation, and security if the endpoint touches those areas.

If memories surface (PATTERN, PITFALL, DECISION entries), read the full memory files for relevant ones:

ls .agent/knowledge/memories/{patterns,pitfalls,decisions}/ 2>/dev/null

What to do with what you find:

• Patterns: apply them (e.g. "we use Zod for validation, not Joi")
• Pitfalls: avoid them (record in pitfalls_avoided in Step 8)
• Decisions: respect them (e.g. "we return 404 over 422 for missing resources")

If the graph returns nothing useful, proceed without it. Skip this step only if the knowledge graph is disabled in .agent/.nav-config.json.

Step 1: Gather Endpoint Requirements

Ask user for endpoint details:

Endpoint path: [e.g., /api/users/:id]
HTTP method: [GET, POST, PUT, PATCH, DELETE]
Resource name: [e.g., User, Post, Product]

Framework:
  - express (default)
  - fastify
  - nestjs
  - nextjs   (App Router Route Handler — app/api/<resource>/route.ts)
  - graphql

Authentication required: [yes/no]
Request validation needed: [yes/no]

Validate endpoint path:

• Use predefined function: functions/route_validator.py
• Ensure RESTful conventions
• Check path parameters syntax
• No trailing slashes

Step 1.5: Verify Understanding (ToM Checkpoint) [EXECUTE]

IMPORTANT: This step MUST be executed for high-stakes operations.

Before generating code, confirm interpretation with user.

Display verification:

I understood you want:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Endpoint: {METHOD} {PATH}
Resource: {RESOURCE_NAME}
Framework: {FRAMEWORK} (detected from package.json / specified)
Auth required: {yes/no}
Validation needed: {yes/no}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Assumptions I'm making:
- Using {VALIDATION_LIBRARY} for validation (detected from existing validators)
- Error handling follows existing pattern in {ERROR_HANDLER_PATH}
- Route will be registered at {ROUTE_PREFIX} prefix

Proceed with generation? [Y/n]

Skip verification if (HIGH-STAKES ONLY mode):

• Simple CRUD operation (single resource, single path parameter)
• User explicitly said "quick", "just do it", or "skip confirmation"
• No custom authentication logic specified
• Standard GET/POST/PUT/DELETE without complex business logic

Always verify if:

• Multiple path parameters (e.g., /users/:userId/posts/:postId)
• Custom authorization logic specified
• Non-standard HTTP methods or patterns
• GraphQL mutations with side effects
• Endpoints involving financial or sensitive data

Step 1.8: Declare Belief State (Optional - ToM Anchor)

Before generating code, optionally declare explicit assumptions (enabled by tom_features.belief_anchors in config).

Display belief state anchor:

📌 BELIEF STATE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

What I know (from context):
✅ Framework: {FRAMEWORK} (from package.json)
✅ TypeScript: {strict/normal} mode (from tsconfig.json)
✅ Validation: {LIBRARY} (from existing validators/)

What I'm assuming (inference):
🔸 Error handler follows pattern in {PATH}
🔸 Routes registered at {PREFIX} prefix
🔸 Using {CONVENTION} commit messages

What I don't know (using defaults):
❓ Request logging preference (will include)
❓ Rate limiting requirements (will skip)
❓ Response envelope format (will use standard)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Adjustments needed before I proceed?

Skip belief anchor if:

• tom_features.belief_anchors is false in config
• User said "skip", "just do it", "quick"
• Simple endpoint with no custom logic

Show belief anchor if:

• Complex endpoint with multiple integrations
• User profile indicates preference for detailed explanations
• First endpoint in a new project (establishing patterns)

Step 2: Generate Route Handler

Based on HTTP method and framework:

Use predefined function: functions/endpoint_generator.py

python3 functions/endpoint_generator.py \
  --path "/api/users/:id" \
  --method "GET" \
  --resource "User" \
  --framework "express" \
  --auth true \
  --validation true \
  --template "templates/express-route-template.ts" \
  --output "src/routes/users.ts"

Template includes:

• Route definition
• Request validation middleware
• Controller/handler function
• Error handling
• Response formatting
• TypeScript types

Step 3: Generate Validation Schema

Use predefined function: functions/validation_generator.py

python3 functions/validation_generator.py \
  --resource "User" \
  --method "POST" \
  --fields "name:string:required,email:email:required,age:number:optional" \
  --library "zod" \
  --output "src/validators/user.validator.ts"

Supported validation libraries:

• Zod (default, TypeScript-first)
• Joi (JavaScript schema)
• Yup (object schema)
• Express-validator (middleware-based)

Output example (Zod):

import { z } from 'zod';

export const createUserSchema = z.object({
  name: z.string().min(1),
  email: z.string().email(),
  age: z.number().optional(),
});

export type CreateUserInput = z.infer<typeof createUserSchema>;

Step 4: Generate Error Handling Middleware

Write the error handler inline (no generator script ships for this — author it directly to match the project's existing error-handling pattern).

Write to src/middleware/errorHandler.ts an error handler that includes:

• HTTP status code mapping
• Error response formatting
• Logging integration
• Development vs production modes
• Validation error handling

Follow the framework's idiom (Express error middleware (err, req, res, next); Next.js route-level try/catch returning NextResponse.json).

Step 5: Generate Test File

Write the test inline, using templates/endpoint-test-template.spec.ts as the reference shape (it ships as a reference template; no generator script drives it). Output to tests/routes/users.test.ts.

The test should cover:

• Success case (200/201)
• Validation errors (400)
• Not found (404)
• Unauthorized (401)
• Server errors (500)
• Edge cases

Example test:

describe('GET /api/users/:id', () => {
  it('returns user when found', async () => {
    const response = await request(app)
      .get('/api/users/123')
      .expect(200);

    expect(response.body).toMatchObject({
      id: '123',
      name: expect.any(String),
    });
  });

  it('returns 404 when user not found', async () => {
    await request(app)
      .get('/api/users/999')
      .expect(404);
  });
});

Step 6: Generate API Documentation Comment

JSDoc or OpenAPI annotation:

/**
 * @route GET /api/users/:id
 * @description Get user by ID
 * @access Private
 * @param {string} id - User ID
 * @returns {User} User object
 * @throws {404} User not found
 * @throws {401} Unauthorized
 */

Step 7: Show Endpoint Summary

Display generated files and usage:

✅ Endpoint Created: GET /api/users/:id

Structure:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📁 src/
   ├── routes/users.ts                (Route handler)
   ├── validators/user.validator.ts   (Request validation)
   └── middleware/errorHandler.ts     (Error handling)

📁 tests/
   └── routes/users.test.ts           (Integration tests)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Route Registration:
import { userRoutes } from './routes/users';
app.use('/api', userRoutes);

Test:
curl http://localhost:3000/api/users/123
# or
npm test -- users.test.ts

Next Steps:
1. Implement business logic in controller
2. Connect to database/service layer
3. Run tests: npm test
4. Test with Postman/Thunder Client

Step 8: Emit Execution Summary (Graph Ingestion)

After Step 7, emit an execution_summary JSON block. This is the parity equivalent of the research_findings block emitted by navigator-research, ingested into the knowledge graph so future endpoint work can surface what we learned.

Output the block verbatim (replace placeholders with actual values):

{
  "execution_summary": {
    "skill": "backend-endpoint",
    "task": "{METHOD} {PATH}",
    "files_created": ["{route, validator, test paths}"],
    "files_modified": ["{router registration paths}"],
    "tests_added": ["{test file path}"],
    "stack_detected": "{e.g. express+typescript+zod}",
    "patterns_followed": [
      {"summary": "{convention applied — e.g. Zod schema for request validation}", "concepts": ["api"], "confidence": 0.8}
    ],
    "decisions_made": [
      {"summary": "{non-obvious choice — e.g. 404 over 422 because resource itself missing}", "concepts": ["api"], "confidence": 0.75, "evidence": "{path:line}"}
    ],
    "pitfalls_avoided": [
      {"summary": "{gotcha that future agents should know — e.g. middleware order matters: auth before validator}", "concepts": ["api"], "confidence": 0.85}
    ],
    "assumptions_made": ["{e.g. project uses Express middleware pattern (detected via package.json)}"]
  }
}

Ingestion (run from project root):

PLUGIN_DIR="${CLAUDE_PLUGIN_ROOT:-$(cat "${NAVIGATOR_CONFIG_HOME:-${XDG_CONFIG_HOME:-$HOME/.config}/navigator}/plugin-root" 2>/dev/null)}"
[ -d "$PLUGIN_DIR/skills" ] || PLUGIN_DIR="$HOME/.claude/plugins/marketplaces/navigator-marketplace"
echo '<execution_summary JSON>' | python3 "$PLUGIN_DIR/skills/nav-graph/functions/execution_to_graph.py" -

Rules:

• Only include non-obvious entries — empty/trivial blocks pollute the graph.
• Skip the entire block if there's nothing notable to record.
• Confidence ≥ 0.7 for first-hand execution; 0.75 is a reasonable default.

Predefined Functions

1. route_validator.py

Validates route path follows REST conventions.

Usage:

python3 functions/route_validator.py --path "/api/users/:id" --method "GET"

Checks:

• RESTful naming (plural resources)
• Path parameter syntax (:id or {id})
• No trailing slashes
• HTTP method matches intent

Returns: Valid path or error message

2. endpoint_generator.py

Generates endpoint handler from template.

Usage:

python3 functions/endpoint_generator.py \
  --path "/api/users/:id" \
  --method "GET" \
  --resource "User" \
  --framework "express" \
  --auth true \
  --validation true \
  --template "templates/express-route-template.ts"

Parameters:

• --path: API endpoint path
• --method: HTTP method
• --resource: Resource name (singular, PascalCase)
• --framework: Backend framework
• --auth: Include auth middleware
• --validation: Include validation middleware
• --template: Template file path

Returns: Generated endpoint code

3. validation_generator.py

Generates request validation schema.

Usage:

python3 functions/validation_generator.py \
  --resource "User" \
  --method "POST" \
  --fields "name:string:required,email:email:required" \
  --library "zod"

Supported field types:

• string, number, boolean
• email, url, uuid
• array, object
• date, datetime

Returns: Validation schema code

Error handling and tests are written inline (Steps 4–5) — no error_handler_generator.py / test_generator.py ship with this skill.

Templates

express-route-template.ts

Express.js route handler template.

Placeholders (exactly those present in templates/express-route-template.ts):

• ${ROUTE_PATH} - API endpoint path
• ${HTTP_METHOD} - HTTP method (uppercase)
• ${HTTP_METHOD_LOWER} - HTTP method (lowercase, for the router call)
• ${RESOURCE_NAME} - Resource name (PascalCase)
• ${RESOURCE_NAME_LOWER} - Resource name (lowercase)
• ${MIDDLEWARE_BLOCK} - Auth + validation middleware chain (built by endpoint_generator.py from the --auth/--validation flags)