Node.js API v24 operator

Add, inspect, or troubleshoot authentication and authorization for Node.js APIs using existing API-key, bearer-token, JWT, session, or framework middleware patterns. Use when an endpoint needs protection, returns 401 or 403 unexpectedly, or authentication behavior must be reviewed without exposing credentials.

Answer common Node.js API command and implementation questions with concise, safety-aware examples for runtime inspection, route work, validation, authentication, HTTP clients, tests, logs, and diagnostics. Use when the user asks what Node.js API command or pattern to use, wants a quick reference, or needs a command translated into plain language.

Add database access and CRUD endpoints to a Node.js API, covering one pool per process and its sizing, parameterized queries, a repository layer separate from handlers, transactions across related writes, mapping database errors to status codes, migrations as the schema owner, connection handling in serverless runtimes, and closing the pool on shutdown. Use when an API must read or write a database, when CRUD endpoints must be added, or when connection or query errors appear under load.

Inspect a Node.js API project's runtime, package manager, framework, scripts, entrypoints, configuration, dependencies, and local prerequisites without changing the environment. Use when a project is unfamiliar, a task needs an evidence-based starting point, or the user asks whether the API is configured or runnable.

Design, repair, or review Node.js API error handling with stable status mapping, structured responses, async propagation, safe logs, and no accidental stack-trace or secret disclosure. Use when an API returns inconsistent errors, crashes on rejected promises, exposes internals, or needs a consistent error middleware pattern.

Add a GraphQL surface to a Node.js API safely, covering schema-first types and resolvers, the N-plus-one problem and batching, depth and complexity limits, disabling introspection and persisted queries in production, authorization per field rather than per request, errors and partial results, pagination conventions, and why a single endpoint defeats path-based rate limiting. Use when a GraphQL endpoint must be added, when queries are slow from repeated database calls, or when a GraphQL surface must be reviewed for abuse resistance.

Implement or review outbound HTTP calls from Node.js APIs with the project's existing fetch, undici, axios, or wrapper conventions, including timeouts, safe retries, response checks, error mapping, authentication, and tests. Use when an API calls an upstream service or fails on timeout, non-success responses, malformed data, or connection errors.

Connect a Node.js API to its dependencies, covering database clients and connection pooling, cache and queue workers, authentication providers and webhook receivers, structured logging with request correlation, tracing and metrics, container images and reverse proxies, and pipeline test and deploy steps. Use when an API must reach a datastore or upstream service, when a webhook endpoint must verify signatures, when requests need correlation across services, or when the API must run behind a proxy or in a container.

Move slow work off the request path into background jobs, covering a durable queue rather than a floating promise, enqueuing inside the transaction that creates the work, idempotent handlers and retries with backoff, a dead letter queue, concurrency and ordering, scheduled and repeating jobs, a separate worker process, graceful shutdown mid-job, and observability. Use when a request is slow because of work that could happen later, when a job runs twice or is lost, or when a worker must be added.

Generate, serve, and check an OpenAPI description of a Node.js API, covering generating the document from the validation schemas that already run rather than hand-writing it, documenting error shapes and security schemes, serving the document and an interactive page, keeping it honest with a drift check in the pipeline, and versioning it alongside the API. Use when an API needs a published contract, when the existing document has drifted from the code, or when clients need a generated SDK.

Add pagination, filtering, and sorting to a list endpoint, covering offset versus cursor paging and when each is correct, a stable sort key, clamped page sizes, allow-listed filter and sort fields, total counts and their cost, the indexes each query shape needs, and a consistent response envelope. Use when a list endpoint returns everything, when paging skips or repeats rows, or when filtering and sorting must be exposed without opening a query surface.

Add rate limiting to a Node.js API without blocking legitimate traffic, covering the key choice of address versus authenticated identity, trusting forwarded headers behind a proxy, a shared store across instances, per-route limits for expensive and authentication endpoints, the standard response headers and 429 status, burst allowance, and excluding health checks. Use when an API must be protected from abuse, when a limiter blocks real users, or when limits reset unexpectedly across instances.

Inspect, add, change, or verify Node.js HTTP routes while preserving the project's framework, router registration, middleware order, response envelope, status codes, naming, and test conventions. Use when the user asks to create or modify an endpoint, route a handler, expose a resource, or understand where an API route is implemented.

Start, inspect, health-check, observe, and safely stop a local Node.js API server using the project's own scripts and discovered port configuration. Use when the user wants to run an API locally, verify that it responds, inspect logs, investigate a port conflict, or stop a process created for the task.

Scaffold a Node.js HTTP API from zero, choosing a framework, setting up TypeScript and the module system, loading configuration from the environment with validation, adding a graceful shutdown and a health route, and wiring development, build, lint, and test scripts. Use when a repository has no API server yet, when an existing project needs its runtime and scripts brought into working order, or when the user asks how to start a Node.js API.

Create and run focused tests for Node.js APIs, including handler, middleware, route, integration, upstream-client, and contract behavior, while using the project's existing test runner and avoiding real production services. Use when an endpoint changes, a regression needs coverage, or API behavior must be verified.

Diagnose Node.js API startup, port, routing, validation, authentication, runtime, upstream, test, and dependency failures through bounded evidence collection and the least invasive next step. Use when the user provides an error, an API is not responding, a route returns an unexpected status, or a Node.js service behaves inconsistently.

Accept file uploads safely in a Node.js API, covering size limits enforced by the server, content type verified from the bytes rather than the client's claim, filename sanitizing and path traversal, storing outside the application and never executing uploads, presigned direct-to-storage uploads for large files, virus scanning, per-user quotas, and cleaning up orphaned objects. Use when an endpoint must accept a file, when an upload exhausts memory or disk, or when upload handling must be reviewed for safety.

Add, repair, or review validation for Node.js API bodies, query strings, path parameters, and headers using the project's existing schema library and error conventions. Use when an endpoint accepts user input, rejects malformed requests inconsistently, or needs a clear validation contract and tests.

Introduce an API version and retire an old one without breaking clients, covering what counts as a breaking change, URL path versus header versioning, running two versions from one codebase with a shared service layer, additive changes that need no new version, deprecation headers and sunset dates, measuring real client usage before removal, and the removal sequence. Use when a change would break existing clients, when a second version must be introduced, or when an old version must be retired safely.