Generate an n8n Node from an OpenAPI Spec: What Works

This is the written version of Part 10 of Build your own n8n node, the last part. Nine parts built one node by hand. This one puts the same API through NativeShip, the tool we build: you give it an OpenAPI spec, and it gives you an n8n node package.

Here's where it ends up: a built package, five checks passed, in twenty seconds. This guide shows what it gets right, what it gets wrong, and who shouldn't buy it.

Everything below is from a real project built on nativeship.io on 2 October 2026, from the Acme CRM spec used across the series.

Why this came last

At the end of every part, we mentioned NativeShip in a sentence. The rest of each part showed how to never need it.

That was on purpose. If you've followed along, you know every step, and which parts are hard and which are typing. So you can judge what a generator does, and you'll see straight away if it isn't good.

The one thing it needs: an OpenAPI 3 spec

NativeShip needs one thing from you: an OpenAPI spec of your API, version 3.

If you haven't met one, it's a file that describes your API: every endpoint, every field, and how authentication works. A lot of teams already have one, because it's what their API docs are generated from. If you don't, that matters, and it comes up again below.

How good the node is depends a lot on how good the spec is. The OpenAPI best practices guide covers the fields that make the difference.

The import

A new project takes a project name, the node name and the spec, uploaded as a file, pasted, or fetched from a URL. NativeShip reads the document, checks the operations and the authentication, and opens the project.

From the Acme CRM spec it found:

• Contact, with five operations, and Deal, with five more
• the login: a bearer token, sent in the Authorization header

That's Part 3 and Part 4, read out of the spec, including all the repetitive copying where one small typo hides in the middle.

Shaping it

It isn't finished out of the box. In the editor's n8n preview, one operation came through as "Create A". The spec's summary said "Create a contact."

n8n's word is Create. So we renamed it, added a description, and the preview changed as we typed.

That's Part 6. Your spec is written in your API's words, and your users need n8n's words. A generator can't make that judgement for you. It can make it quick.

The build

Then the build. It writes the package, locks and installs its dependencies, compiles it, runs n8n's linter, and validates the requests. Five checks, all passed, in 20 seconds. The package came out at 186.7 kB.

That's the wall of lint errors from Part 7, handled by a machine. This one was generated in the declarative style. Generated packages have no run-time dependencies, and the node is marked as usable by n8n's AI Agent, so it also works as an agent tool.

One thing this build can't show: the node calling a real API. Acme CRM is invented, and there's no server behind it.

What it didn't do: pagination

Here's the part we most want you to see. Under the checks, the build page showed a warning:

List contacts looks paginated, but no explicit safe pagination contract is available. The generated operation remains single-page.

Remember Part 5? Fifty contacts out of 1,240.

The spec has a cursor parameter and a next field. That wasn't enough for NativeShip to be sure how the paging works, so it didn't guess. It built a one-page operation and said so. To get Return All, the paging rules have to be stated in the spec. By hand, you write that loop yourself.

We'd rather show that warning than hide it.

What a spec can't know

One more limit, and this one is by design. In Part 5, one operation found a contact by email and then created a deal for it: two endpoints joined into one action.

A spec describes endpoints one by one. It doesn't know you wanted two of them joined. That was your idea, and it isn't written anywhere in your API. Anything like that, the custom pieces, is still handwork.

By hand vs generated

	By hand	NativeShip
Getting to a built package	nine parts of work	upload a spec, a 20-second build
Code you write	all of it	none
Wording	you choose every label	you fix what the spec got wrong
Paging	you write the loop	only when the spec states the rules
Custom logic	anything you like	what the spec describes
Cost	your time	$79, once

Who shouldn't use it

The part an ad would leave out:

• No OpenAPI spec? Don't use it. No spec, no node.
• Mostly custom logic? If the node is mostly behaviour that isn't your API's endpoints, build it by hand. You know how now.
• One small node for yourself? Build it by hand. It's a good weekend, and you'll learn a lot.

Who is it for, then? The person from Part 1. You have a product and an API, customers keep asking about n8n, and you have forty other things to do this month. If they're asking about Zapier and Make too, here's what each integration costs to build.

The price

$79, once. No subscription and nothing to cancel.

That's one node and three build jobs. A build job is one full run, like the one above. Importing or re-importing your spec doesn't use a build, so you can get the spec right first.

The reply

Back to where the series started:

"Hey, love the product. Quick question. Do you support n8n?"

"Yes. Here's the link."

However you get there, by hand or with a tool, that's the reply we want you to be able to send. If you built your node by hand with this series, we'd love to see it.