n8n REST API Tutorial: GET, POST, PUT, and DELETE with the HTTP Request Node

If you’ve ever hit a wall in n8n because the native node for a service doesn’t support the exact action you need, the HTTP Request node is the solution. It lets you call any REST API directly — meaning if a service has an API, you can connect to it in n8n, regardless of whether there’s a dedicated node for it.

This tutorial breaks down the four core HTTP methods — GET, POST, PUT, and DELETE — and shows you exactly how to use each one inside n8n’s HTTP Request node. All examples use JSONPlaceholder, a free public API with no authentication required, so you can follow along and test everything immediately.

What Is a REST API?

A REST API is a standardized way for different software applications to communicate over the internet using HTTP — the same protocol your browser uses to load web pages. It’s the most widely used API architecture today because it’s simple, scalable, and flexible.

Every REST API interaction involves an HTTP method that tells the server what kind of operation you’re performing. The four you’ll use most are GET (read data), POST (create data), PUT (update data), and DELETE (remove data). In n8n, each of these maps directly to an option inside the HTTP Request node’s Method dropdown.

In practice, most workflows need more than one method. It’s very common to POST to create a resource and then GET to retrieve it, or GET a list of items and DELETE specific ones based on filter logic. The HTTP Request node can be chained with other nodes — filters, wait nodes, edit fields — to build these multi-step flows.

The JSONPlaceholder Test API

All examples in this tutorial use JSONPlaceholder (jsonplaceholder.typicode.com), a free public API designed specifically for testing and prototyping. It supports GET, POST, PUT, PATCH, and DELETE — no API key, no account, no authentication required.

JSONPlaceholder includes several resources: posts, comments, albums, photos, todos, and users. The server simulates successful responses for create, update, and delete operations without actually persisting changes, which makes it safe to experiment with. Check the documentation to see the structure of each resource before building your requests — understanding what fields an API expects is an essential first step for any integration.

GET: Reading Data from an API

GET is the most commonly used HTTP method — it requests data from a server without modifying anything. In n8n’s HTTP Request node, select GET from the Method dropdown and enter your endpoint URL. For JSONPlaceholder, https://jsonplaceholder.typicode.com/todos returns all 200 to-do items.

To retrieve a specific record, append the ID to the URL: /todos/1 returns just the first to-do. You can also use Query Parameters to filter results directly in the request. For example, adding a query parameter userId=5 asks the API to return only items belonging to user 5 — this is far more efficient than fetching all 200 items and filtering afterward in n8n.

After a GET request, it’s common to add an Edit Fields node to extract only the specific fields you need. If you only need the title of a post, map just title in Edit Fields and discard the rest. This keeps your workflow data clean and avoids passing unnecessary fields through downstream nodes.

For more complex data manipulation after a GET, a Code node is an option — n8n supports both Python and JavaScript. That said, reach for a Code node only when native nodes can’t solve the problem. Edit Fields and Filter nodes handle the majority of common post-request cleanup without any code.

POST: Creating New Resources

POST submits new data to a server to create a resource. Switch the Method dropdown to POST, set your URL (for JSONPlaceholder: https://jsonplaceholder.typicode.com/posts), and configure the body of your request.

The most common body format is JSON. In the HTTP Request node, set Body Content Type to JSON and paste in your payload directly, or use the Fields Below option to define each key-value pair individually. Both approaches work — JSON is useful when you’re pasting in a pre-built payload or referencing data from a previous node, while Fields Below is more readable when you’re building the body manually.

To post multiple records at once, wrap your JSON objects in an array (square brackets) with commas between them. JSONPlaceholder accepts this and returns a success response for each item. Always check the API documentation to confirm whether bulk creation is supported and what array format the endpoint expects.

A common pattern is triggering a POST from a form. You can connect an n8n Form trigger to an HTTP Request node, collect user input through the form, and pass those values directly into the POST body. This is particularly useful for scraper workflows where a user submits a target URL via a form, or for image/video generation APIs where parameters are collected upfront before kicking off the workflow.

To verify your POST succeeded, enable Include Response Headers and Status in the node options. A 201 Created status code confirms the resource was created. JSONPlaceholder returns a 200 with a “created” message since it simulates the operation without actually persisting data.

PUT and PATCH: Updating Existing Resources

PUT and PATCH both update resources, but they work differently. PUT replaces the entire resource — you must include all fields, even ones you’re not changing. PATCH is a partial update — you only send the fields you want to modify.

In n8n, both appear in the Method dropdown and work identically in terms of configuration: set the URL to include the resource ID you’re updating (e.g., /posts/1), choose JSON as the body type, and include the relevant fields. JSONPlaceholder supports both methods on the same endpoints.

In practice, GET and POST account for roughly 95% of real-world API usage. PUT, PATCH, and DELETE are used less frequently but are essential for workflows that manage data — updating a CRM record, syncing statuses, or cleaning up stale entries.

DELETE: Removing Resources

DELETE removes a resource from the server. In n8n, select DELETE from the Method dropdown and set the URL to include the specific resource ID you want to remove (e.g., https://jsonplaceholder.typicode.com/todos/2). No body is typically required.

Enable Include Response Headers and Status to confirm the operation worked — a 200 status code means the deletion was successful. JSONPlaceholder confirms the delete without actually removing anything, since it’s a testing API.

Advanced Example: Chaining GET and DELETE

One of the most powerful things about the HTTP Request node is that it can be chained with other n8n nodes to create multi-step logic. A common pattern is to GET a list of resources, filter them based on some condition, and then DELETE the matching ones.

For example: start with a GET to /todos to fetch all 200 to-dos, then add a Filter node to keep only items where userId equals 2 (which returns 12 items), and finally pipe those into an HTTP Request node set to DELETE with the to-do ID passed in via expression. The workflow processes each item individually, making one DELETE request per filtered record.

The result: 12 targeted deletions, driven entirely by the data returned from the initial GET. This GET → Filter → DELETE pattern applies to any API that supports both methods on the same resource type.

The POST → Wait → GET Pattern

Another very common REST pattern is creating a resource and then retrieving it after some processing time. POST to trigger an operation (image generation, a scraper run, a report build), add a Wait node to pause the workflow for however long the operation takes, and then GET the result.

The wait duration depends entirely on the API. A simple data creation might need no wait at all. An image generation API might need 10–15 seconds. A complex scrape could take a minute or more. Set the Wait node duration based on what the API documentation specifies, or what you observe from testing.

This POST → Wait → GET sequence is the backbone of many real-world n8n automations involving third-party services where operations aren’t instantaneous.

Next Steps: Authentication and Advanced Use Cases

This tutorial focused on the fundamentals using a public, unauthenticated API. Most production APIs require authentication — API keys, OAuth tokens, Bearer tokens, or Basic Auth. The n8n HTTP Request node supports all of these through its Authentication settings.

For a deeper dive into authentication, real-world API integrations (including SerpAPI and other commonly used services), and advanced HTTP Request patterns, the full hour-long n8n HTTP Request tutorial covers all of this in detail — it’s in the Ryan & Matt Data Science n8n playlist and pairs well with the pagination guide for anyone working with data-heavy APIs.