Why Your n8n HTTP Request Node Gets a Login Page Instead of JSON - And How to Fix It

This common integration failure stems from server-side access controls or routing that expect an authenticated session, certain headers, or a user-agent. Browsers succeed because they send cookies, stored SSO tokens, or interactive negotiators (OAuth redirects). n8n's HTTP Request node, by contrast, needs explicit credentials, token exchange, or header configuration to receive JSON payloads programmatically.

Practical debugging starts with inspecting the raw HTTP status and headers (3xx redirects, 401/403 responses). Enable full response logging in n8n to capture Location, Set-Cookie, and WWW-Authenticate headers. Next, reproduce the request with curl from the n8n host to identify server-side conditions (IP allowlists, TLS client cert requirements, or conditional routing). Ensure the node's "Follow Redirects" option is set appropriately and that the Accept header is set to application/json.

Solutions vary by auth regime: for OAuth/SSO, implement a service account flow or token exchange and refresh the token programmatically; for cookie-based sessions, use a login step that captures cookies and reuses them for subsequent calls; for API keys, populate the Authorization header securely using n8n credentials. Avoid embedding credentials in plaintext and use the platform's secrets store or a dedicated vault.

For executives, the key is to treat integrations as first-class services with secure authentication patterns and observability. Standardize service accounts for machine-to-machine calls, enforce centralized secrets management, and include integration tests in CI to detect regressions early. This reduces outages caused by environment drift and interactive-only endpoints that break automated workflows.