[AdaAibaby]

What

The shared request-logging middleware (packages/shared/pkg/middleware/logging.go) picks the access-log level purely from the status code, so every 4xx is logged at WARN. On a public endpoint the 404 stream is dominated by bots/scanners probing /.env, /HNAP1, /favicon.ico, /robots.txt, /login, … — observed ~1500 no matching operation was found WARN lines on a dev api, burying the warnings that actually matter.

This logs 404 at Info; other 4xx (401/403/429/validation) stay Warn, 5xx stays Error. Complements #3784 (which fixed the same external-scanner-noise-at-WARN pattern on the client-proxy side); this fixes it at the API's shared HTTP middleware.

Refs #3783.

Why 404 specifically

A 404 means the client asked for a route that doesn't exist — legitimate SDK/dashboard traffic hits real routes, so 404s are overwhelmingly external probes or typos, not an operational signal. Other 4xx can carry intent (auth failures, rate limiting, bad request bodies) and stay at Warn.

How

Extract levelForStatus(status int, def zapcore.Level) zapcore.Level and call it in the middleware. Behavior is identical except 404 moves from Warn to Info — response codes and everything else are unchanged.

5xx            -> Error
404            -> Info   (new)
other 4xx      -> Warn
< 400          -> DefaultLevel

Test

TestLevelForStatus asserts the mapping across 2xx/3xx/404/400/401/403/429/5xx. go test ./packages/shared/pkg/middleware/ passes.