Short answer: Set the method and URL first. Then choose the credential type, add query or body data, test one response, and only then configure pagination.

What does the HTTP Request node do?

The HTTP Request node calls an API from an n8n workflow. It can send a request, add headers, pass query values, and return the response to the next node.

Start with one known request. Confirm the status code and response fields before connecting more nodes.

How should you set the method and URL?

Choose the method that matches the API action. Use GET to read data. Use POST to create a record. Use PUT or PATCH to update one. Use DELETE only when the API and workflow both require removal.

Keep the base URL and path clear. Put changing values in query parameters or the request body. Do not hide required values in a long expression when a field can show them directly.

Which authentication method should you use?

Use the credential type required by the API. Common choices include an API key, basic authentication, bearer token, OAuth2, and a custom header.

Store secrets in n8n credentials. Do not paste a token into a node expression or a static text field. Limit the credential to the smallest access scope that works.

For the wider credential decision, see OAuth2, API keys, and credential vault choices.

Official HTTP Request node documentation

Where do query parameters and headers belong?

Use query parameters for filters, search terms, page numbers, and limits. Use headers for content type, accepted response format, correlation IDs, and API-specific metadata.

Keep the names exactly as the API documents them. A spelling difference can produce a valid response with the wrong data.

How should you send a JSON body?

Select the JSON body option when the API expects JSON. Match the field names and value types in the API example.

Test with the smallest valid body. Add optional fields one at a time. This makes a validation error easier to locate.

How do you handle pagination?

First identify the API’s pagination model. It may use a page number, an offset, a cursor, or a next-page URL.

Use the model shown by the API. A page number needs a stop condition. A cursor needs the next cursor from the previous response. A next-page URL should be followed only when the response supplies one.

Set a maximum page count or another safety limit. This prevents a bad response from creating an endless loop.

What should you test before using the request in production?

1. Run one request with a known record or filter.
2. Check the status code and the response shape.
3. Test an empty result and an authentication failure.
4. Confirm that sensitive values are not written into logs or output fields.
5. Test pagination with a small limit and a clear stop condition.

When the request returns data, use the Set node for data mapping before adding business logic. For a broader connector map, see n8n integration nodes.