How to fix n8n HTTP Request Bearer auth 401 with pagination

TL;DR: Enabling pagination on n8n's HTTP Request node swaps a working Bearer token for the literal string "hidden," causing 401; fix it with a manual Authorization header on the node and inside Pagination.

This hits any workflow using Generic Credential Type / Bearer Auth on the HTTP Request node the moment pagination gets switched on - Slack's paging-token pagination, self-hosted APIs, plain REST endpoints, all fail the same way. That breadth is the tell: the bug lives in n8n's pagination request builder, not in whatever API you're calling.

Why does n8n's HTTP Request node return 401 only when pagination is on?

Without pagination, the HTTP Request node sends the real Bearer token and the request succeeds. Turn pagination on for the same node and credential, and every follow-up page comes back 401 Unauthorized - even though nothing about the target API or the credential changed.

A user on the n8n GitHub issue tracking this bug inspected the outgoing request in the browser's dev console and found the actual cause: the Authorization header isn't missing, it's sending the literal string 'hidden' - the credential field's masked-value placeholder in the n8n editor UI - instead of substituting the real token. n8n's pagination sub-request builder constructs its own header set for follow-up pages and doesn't pull the resolved credential value the way the first, non-paginated request does. n8n staff confirmed the bug and opened an internal ticket (GHC-2340); as of this writing the issue is still open, reproduced independently across n8n 1.92.0 through 1.97.1.

How do you fix the Bearer auth 401 error with pagination enabled?

1. Switch the node's Authentication to None. Stop relying on Generic Credential Type / Bearer Auth for this specific node - it's the code path that drops the real token during pagination.
2. Add a manual header on the node. Under Headers, add Name: Authorization, Value: Bearer <your-token> (or an expression referencing an environment variable or a separate credential you resolve yourself).
3. Duplicate the same header inside the Pagination section. Open Pagination, and under its own Headers block add the identical Authorization: Bearer <your-token> row. The pagination sub-requests do not inherit headers set only at the top level of the node.
4. Re-run the workflow. Every paginated page should now return data instead of 401 on page two onward.

How do you verify the fix worked?

Open the execution log for the run and inspect a paginated request's outgoing headers, or use your browser's dev tools network tab while testing. The Authorization value should show your actual Bearer token, not the string hidden. If every page in the response now contains real records instead of a 401 body, the fix took.

What if the fix didn't work?

A few adjacent causes to rule out before assuming the manual-header workaround failed:

• If you're using OAuth2 credential type rather than Generic/Bearer, community reports on the same issue describe the identical symptom with OAuth2-stored credentials, not only Bearer Auth. The workaround is the same shape, but you'll need to paste in a raw access token, which won't auto-refresh once it expires.
• The drop reproduces on both pagination modes - "Response Contains Next URL" and "Update a Parameter in Each Request" - so switching modes will not sidestep it; the manual header still has to go in both places.
• If the Authorization header disappears even after this fix, double-check you didn't leave a second, conflicting Authentication method selected on the node - a leftover Basic Auth or OAuth2 selection can override the raw header.
• If the 401 shows up on a credential test or the very first workflow run rather than only on paginated pages, that's a different bug entirely - see n8n's OAuth callback URL returning 401 for the redirect-URI mismatch that usually causes it.

For other authentication failures on the same node - including HTTP Request node connection errors that look similar but aren't credential-related - or a broader catalog of n8n failure modes, see the Automation Error Index.

FAQ

What causes n8n's "401 Unauthorized" error only when pagination is enabled?

n8n's pagination sub-request builder sends the literal placeholder string "hidden" as the Authorization header value instead of the resolved Bearer token, so every paginated request after the first fails authentication. This is tracked as GitHub issue #16005.

Does this bug affect OAuth2 credentials, or only Bearer Auth?

The confirmed bug report is against Generic Credential Type / Bearer Auth, but multiple commenters on the same issue describe an identical 401-on-pagination symptom using OAuth2-stored credentials. Apply the same manual-header workaround if you hit it with OAuth2.

Which n8n versions have this bug?

Reported and reproduced from n8n 1.92.0 through at least 1.97.1. The issue was still open as of its last update in April 2026, so treat any version in that range - and likely newer ones until a fix ships - as affected.

Is there an official fix coming?

n8n staff acknowledged the bug and opened internal ticket GHC-2340 to track it, but no fix has shipped as of this writing. Use the manual-header workaround until a release note confirms otherwise.

Does the fix work with both pagination modes?

Yes. Whether you're using "Response Contains Next URL" or "Update a Parameter in Each Request," the pagination sub-requests build their headers independently of the node's top-level auth, so the same manual Authorization header has to be added in both the node and the pagination block regardless of mode.

Why does this happen with completely unrelated APIs like Slack and self-hosted tools?

Because the bug is in n8n's own pagination request builder, not in any target API's behavior. Anyone using Generic Credential Type / Bearer Auth with pagination enabled hits the same dropped header, regardless of which service they're calling.