How to Turn an API Into an n8n Community Node

You already have an API.

Now you want people to use it inside n8n.

The first thought is usually:

“How hard can it be to make an n8n node?”

And honestly, the actual API call isn't the hard part.

The annoying part is everything around it.

You need to understand the n8n node structure, credentials, parameters, build process, testing, npm, GitHub, publishing, and eventually updates.

So let's break it down.

First, what are you actually building?

An n8n community node is basically a package that adds your integration to n8n.

Instead of asking users to manually configure an HTTP Request node every time, they can get something like:

Your App
   ↓
n8n
   ↓
Your Node
   ↓
Your API

The node gives them a proper n8n experience with things like operations, fields, authentication, and responses.

n8n's official documentation has a full section for creating nodes and covers everything from planning and building to testing and deployment.

Step 1: Understand your API

Before touching n8n, you need to understand your own API.

For example, imagine your API has:

GET    /customers
GET    /customers/:id
POST   /customers
DELETE /customers/:id

You could turn these into n8n operations like:

Customer
 ├── Get Many
 ├── Get
 ├── Create
 └── Delete

This is where a good API structure helps a lot.

If you already have an OpenAPI specification, even better.

It gives you a structured description of your endpoints, parameters, request bodies, responses, and authentication. The same spec is also the starting point for a Zapier integration built from your OpenAPI spec.

Step 2: Create the n8n node

n8n provides a CLI for this. Start a new project with:

npm create @n8n/node@latest n8n-nodes-yourapp

The wizard asks for a template. Pick declarative if your API is plain REST with JSON in and out: you describe each request in the node's properties and n8n makes the call. Pick programmatic if you need custom logic, such as complex pagination, file handling, or a trigger. The declarative node tutorial walks through the first style. n8n's verification rules require the project to be built with this tool, so starting with it saves a migration later.

You then define things such as:

• Node name
• Display name
• Description
• Operations
• Input fields
• Authentication
• API requests
• Output data

A very simplified idea looks like this:

n8n node
   │
   ├── Credentials
   │
   ├── Resource
   │
   ├── Operation
   │
   ├── Parameters
   │
   └── API request

The exact implementation depends on your API and the type of node you're building.

Step 3: Add authentication

This is one of the important parts.

Your API probably needs some kind of authentication.

Maybe it's:

API Key
Bearer Token
Basic Auth
OAuth2

Your n8n node needs to define how those credentials are stored and how they're used when making requests.

n8n has dedicated documentation for creating credential files and using HTTP request helpers, so this isn't something you need to invent yourself. The n8n node credentials guide compares API key, bearer, and OAuth2 setups, and adding a credential test shows how to check a key when the user saves it.

And this part matters because you don't want users manually pasting authentication headers into every operation.

They should ideally connect their account once and use it across the node.

Step 4: Add the operations

Now you turn your API endpoints into something that feels natural inside n8n.

For example, instead of showing users:

POST /v1/customers

you give them:

Resource: Customer

Operation: Create

Name: John
Email: john@example.com

That's one of the main reasons to build a dedicated node in the first place.

You're not just wrapping an API.

You're creating an n8n-native experience around that API.

Step 5: Build and test it

Once the node is created, you need to make sure it actually works.

n8n's documentation includes tools for running nodes locally, linting them, and troubleshooting problems before deployment. The two commands you'll use most are:

npm run dev    # starts n8n with your node loaded and rebuilds on change
npm run lint   # checks the node against n8n's rules

From n8n 3.0, npm run dev (n8n-node dev) starts n8n inside a container, so you need Docker or Podman installed. If you already run n8n yourself, use n8n-node dev --external-n8n and start your instance with N8N_DEV_RELOAD=true.

The n8n 3.0 checklist for community node makers lists everything else to change before your users upgrade.

You'll probably test things like:

• Does authentication work?
• Do all operations work?
• Are required fields validated?
• Does the API response reach n8n correctly?
• Do errors make sense?
• Does the node behave correctly with multiple input items?

This is usually where you discover the small things you didn't think about when writing the first version.

Step 6: Package the node

Now your node needs to become an npm package.

Something like:

n8n-nodes-yourapp

or a scoped name such as @yourcompany/n8n-nodes-yourapp. n8n only recognises packages whose name starts with n8n-nodes- (after the scope, if there is one) and whose package.json includes the n8n-community-node-package keyword. The scaffold sets both for you.

The package contains the compiled node code and the metadata n8n needs.

At this point, you're moving from:

"I built an n8n node"

to:

"People can actually install my n8n node."

Those are two different things.

Step 7: Publish it

This is where GitHub, npm, CI/CD, and Trusted Publishing start showing up.

Your typical flow becomes:

Code
  ↓
GitHub
  ↓
Build
  ↓
Test
  ↓
npm
  ↓
n8n users

For automated publishing, npm Trusted Publishing can allow a supported CI/CD workflow to publish without keeping a long-lived npm publishing token in the repository.

I wrote a little more about that in What is Trusted Publishing in n8n Community Nodes?. It's no longer optional: from May 1, 2026, n8n requires all community nodes to be published from a GitHub Action with npm provenance.

And n8n also has official documentation covering how to deploy and submit community nodes.

Submitting for verification matters more than it used to. From n8n 3.0, self-hosted instances turn off unverified community nodes by default, and n8n Cloud only ever offered verified ones. If you want most n8n users to be able to install your node, plan for the verification review from the start: no runtime dependencies, a public MIT-licensed repo, and no environment variable or file system access.

So... that's it?

Technically, yes.

But now you can probably see the problem.

The API request itself might take 20 minutes.

The rest can take much longer.

You have to deal with:

API
 ↓
Node structure
 ↓
Credentials
 ↓
Operations
 ↓
Build
 ↓
Test
 ↓
GitHub
 ↓
npm
 ↓
Trusted Publishing
 ↓
Release

And that's just version one.

What happens when your API changes?

You have to update the node.

Then build it again.

Test it again.

Release a new version.

And if you're building nodes for multiple APIs, this gets repetitive very quickly.

This is exactly why we built NativeShip

This is the part that made us think:

Why are we spending so much time doing all the boring parts around an n8n node?

If you already have an API, you shouldn't have to start every integration from an empty folder.

That's what NativeShip is trying to solve.

NativeShip helps turn your API into an n8n community node and takes care of much of the work around generation, building, repository preparation, and publishing.

Instead of spending your time figuring out the structure of every file, you can start with what you already have.

Your API.

Then NativeShip helps you get from:

Your API
   ↓
n8n Node
   ↓
Build
   ↓
GitHub
   ↓
npm
   ↓
Published node

The important part is that you still own your GitHub and npm accounts.

NativeShip isn't trying to become the owner of your integration.

It's there to make the process easier.

What if my API changes later?

This is actually the bigger problem.

Creating the first version is only half of the job.

Let's say you change:

POST /customers

and add a new field:

companyName

Your n8n node needs to know about that change too.

Otherwise, your API has moved forward while your n8n integration is stuck in the past.

That's why node generation shouldn't just be about creating one package and forgetting about it.

You also need a clean way to rebuild and release it when your API changes.

That's one of the areas we're focusing on with NativeShip. The guide to maintaining an n8n node through API changes covers the release side.

Do you always need a community node?

No.

If you only need to make one API request, n8n's built-in HTTP Request node might be completely enough.

A custom community node starts making more sense when you want to give users a proper integration with:

• Multiple operations
• Reusable credentials
• Friendly parameters
• Better UX
• Consistent API handling
• A package users can install and reuse

So don't build a community node just because you can.

Build one when it makes the experience better for the people using your API.

The simple way to think about it

If you already have an API and want to bring it into n8n, the process is basically:

Have an API
   ↓
Understand the endpoints
   ↓
Design the n8n experience
   ↓
Build the node
   ↓
Add credentials
   ↓
Test it
   ↓
Publish it
   ↓
Maintain it

The code is only one part of the job.

The rest is tooling, packaging, publishing, and maintenance.

And honestly, that's the boring part.

NativeShip exists to make that boring part easier.

You bring the API.

We help with the node.