Why does the HTTP Request node not error when using pagination?

Based on what you described, it appears that when you enable pagination the HTTP Request node no longer treats a 403 response as a node error. Instead, it returns the 403 error in the normal output stream. Without pagination enabled, the node errors out immediately on receiving a 403 response.

Why Does This Happen?

When pagination is configured, the HTTP Request node is set up to process multiple pages of responses. In doing so, it uses a loop to handle each page and aggregates the results. As part of that design, non-2xx HTTP responses (such as a 403) are not thrown as errors (i.e. stopping execution) but are instead included as regular output. This behavior ensures that all iterations are handled consistently, which is why you see the error output as an item rather than as a node-level error.

What You Can Do

• Check and Update Credentials: A 403 error usually indicates an authentication or permission issue. If pagination is not needed, removing it may quickly highlight the credential problem.
• Implement Custom Error Handling: If you need to work with pagination, you might consider adding an additional step in your workflow after the HTTP Request node to check the HTTP status (for example, verifying that each item’s code is 2xx) and handle error cases accordingly.
• Review API Rate Limits and Requirements: Although the error in this case is a 403 (Forbidden), sometimes API permissions or rate limits can lead to unexpected responses. Ensure that the API endpoint you are using supports pagination in the way you have configured it.

Example of Custom Error Handling

You could insert a Function node after the HTTP Request node to check for error codes. For instance:

JAVASCRIPTCopied
const results = items.map(item => {
  if (item.json.code && item.json.code !== 200) {
    throw new Error(`HTTP Request failed with code ${item.json.code}`);
  }
  return item;
});
return results;

This function will throw an error if any returned item has a status code other than 200, allowing you to conditionally manage the error output from the paginated response.

Summary

• Without pagination: The node errors on a 403 response.
• With pagination: The node returns the 403 response as part of the regular output.
• Solution: Use custom error handling after the HTTP Request node or review authentication and API settings.

This behavior is expected when pagination is enabled in n8n and you can manage it with additional nodes to match your workflow requirements.