Can You Import an OpenAPI Spec into a Make Custom App?

No. As of October 2026, Make has no way to import an OpenAPI or Swagger file into a custom app. That's true in the web editor, the VS Code extension and the Make CLI. You build the app's base, connection, modules and RPCs yourself, using the spec as your source material.

Your spec still saves a lot of work. It already describes the base URL, the auth scheme, every endpoint and the request and response shapes. This guide shows how each part of an OpenAPI spec maps to a Make app component, what the spec can't tell you, and what Make checks before it approves a public app.

What Make says about OpenAPI import

Make's custom apps documentation describes two editors: the Make web interface and Visual Studio Code. Neither offers a spec import, and the Make CLI's custom app commands work on one component at a time: apps, connections, modules, RPCs, functions and webhooks. We searched Make's full developer documentation for "OpenAPI" and "Swagger" and found no import feature.

People have asked for one more than once:

• November 2024. A developer asked on the Make community forum whether a YAML or JSON spec could generate a custom app. A Make Community Champion replied that besides endpoints, methods and payloads, an app has to handle "connections, pagination, RPC's and IML functions," which are "things that AI or an import cannot take care of (yet)." He pointed the request to Make's idea exchange.
• December 2025. A SaaS team asked again because they ship new endpoints with every release. A Make employee answered that OpenAPI specs "don't contain any context on how you want those APIs to be presented to users in a Make app." That includes which ID fields need dynamic dropdowns, which parameters belong behind the advanced toggle, and whether a list endpoint should become a polling trigger. He said those are "things we're aiming to handle within an AI-based solution." Nothing like that appears in Make's docs yet.

The same thread points to the one automation route Make does document: the SDK Apps endpoints in the Make API. They let you create apps and their components programmatically with an API token that has the sdk-apps:write scope. You can write your own script that reads a spec and pushes components through that API, but you're writing the converter yourself.

Where you can build a Make custom app

Tool	What it's good for
Make web interface	Building and testing in the browser. This is where review and publishing happen.
VS Code + Make Apps Editor extension	Local development with Git, diffs against the live app, and deploying local changes to Make
Make CLI	Scripting component changes from a terminal or CI
Make API (SDK Apps)	Creating and updating apps and components from your own code

If you plan to generate the app from your spec, use VS Code or the API. The generated output is a set of JSON component files, and both tools let you keep those files in a repo.

How an OpenAPI spec maps to a Make app

A Make app has a small set of components. Here's what each one takes from your spec, and what you have to decide yourself.

Make component	What the spec gives you	What you still decide
Base	servers (base URL), the auth header from securitySchemes, error response schemas	Error handling messages, sanitization of secrets in logs
Connection	The auth type: API key, HTTP bearer or basic, OAuth 2.0 flows and scopes	Connection type (basic, JWT, OAuth 1 or OAuth 2), a validation call that fails on bad credentials, which scopes to request
Action modules	POST, PUT, PATCH and DELETE operations with their request bodies	Module names and labels, which fields are required, which go behind the advanced toggle
Search modules	GET list operations with query parameters	A limit parameter, pagination, and which filters are worth exposing
Triggers	List endpoints that can be sorted by created or updated date	Whether a polling trigger makes sense, and how to track the last item seen
Instant triggers + webhooks	webhooks (OpenAPI 3.1) or callbacks	Shared vs dedicated webhook, attach and detach calls, event payloads
Interface	Response schemas	Which output fields users actually map, and how to label them
RPCs	List endpoints that return IDs and names	Which ID fields get a dynamic options RPC dropdown
Universal module	Nothing directly	Make's review prerequisites require one. It must use a relative path
IML functions	Nothing directly	Custom logic for data the spec can't describe, such as reshaping nested payloads

A spec generator can fill in most of the left-hand column. The right-hand column is product work, and it's what Make's reviewers look at most closely.

Step by step: build a Make app from your spec

1. Clean up the spec first. Give every operation a clear summary, add example values to responses, and mark required fields properly. Make module labels and samples come straight from these, so a messy spec produces a messy app. Our OpenAPI spec best practices guide covers what to fix.
2. Create the app. Do this in the web interface, or in VS Code with the Make Apps Editor extension if you want the components in Git.
3. Write the base. Set the base URL from servers, put the shared auth header in the base, map your API's error format to readable messages, and sanitize any header or parameter that carries a secret.
4. Add the connection. Use the connection type that matches your securitySchemes. Its validation call should hit a cheap authenticated endpoint, such as "get current user", so bad credentials fail at connect time.
5. Choose your modules. Don't turn every operation into a module. Pick the create, update, get, search and delete operations people will actually automate, and leave admin endpoints out.
6. Add search limits and pagination. Make's review expects a limit parameter on search modules, triggers and RPCs, plus pagination wherever the API supports it.
7. Add RPCs for ID fields. Any field where a user would otherwise paste an ID, such as a project, list or owner, should load its options from a list endpoint.
8. Add triggers. Use instant triggers if your API sends webhooks, and polling triggers on list endpoints otherwise.
9. Add the universal module. It lets users call any endpoint you didn't model with their existing connection. An app can have only one, and it must use a relative path. Make won't approve a universal module that doesn't.
10. Format dates. Parse dates in outputs and format date inputs the way your API expects.
11. Test every module in a real scenario. Build at least one scenario per module, plus one that produces an error on purpose. Check the logs for personal data.

Private, public and approved apps

Make's app visibility docs describe three states:

• Private: only you can use the app until it's installed in an organization. Use this while you build.
• Public: clicking Publish generates an invite link anyone can use. A published app can't be deleted or made private again, and its components can't be deleted either. Make suggests relabelling unwanted modules "[DO NOT USE]" and hiding them, so clean out test modules before you publish.
• Approved: Make has reviewed the app and made it available to all Make users.

For a SaaS company, "approved" is usually the goal. It's what puts your app in front of Make users who don't already know about you.

What Make checks before approving an app

Make's review prerequisites are specific. Before you request review, check that:

• The service isn't already available in Make
• Every module connects to your service's API, and the connection asks only for the credentials your service requires
• The base and connection sanitize sensitive data, handle errors, and call an endpoint in your API
• The connection uses the correct URL and returns an error on bad credentials
• Modules have correct labels and descriptions, following Make's naming conventions
• The app has a universal module, and it uses a relative path
• Output interfaces are correct, and dates are formatted and parsed
• Search modules, triggers and RPCs have a limit parameter, plus pagination where the API supports it
• Every module is used in at least one test scenario, and one extra scenario produces an error
• Scenario logs contain no personal data
• You've rerun the test scenarios right before requesting review, because reviewers can't see logs past Make's retention limit

Then follow the request review steps:

1. Remove any test modules.
2. Publish the app.
3. Set which modules are visible.
4. Fill in the Review tab with a link to your API docs and links to your test scenarios.
5. Click Request review.

The app's status changes to "pending approval," and Make emails you with the subject "App review: [your app name]." Review covers a form about your company, support contacts, categories, logo and trademark use, then an automated check and a manual QA review. Make's docs don't publish a review timeline. If your app sits on "pending approval" with no reply, here's how to get a stuck Make or Zapier app review moving. Inovaflow, a Make app agency, estimates four to six weeks of review on top of one to four weeks of building (their published estimate).

Keeping the app in sync with your spec

This is where the lack of an import hurts most. Once an app is approved, every change needs Make's approval again. That includes new or changed connections, modules, RPCs, custom IML functions and webhooks, and even a new theme or logo (approval of changes). You request it with Update review, and Make confirms with an email titled "App Update Review: [your app name]."

So when your spec gains endpoints, you can't simply regenerate and overwrite the app. Treat each release as a diff: add new modules, keep existing ones backward compatible, and submit the update. Keeping the app's JSON in Git through VS Code makes those diffs much easier to review.

Common mistakes when converting a spec

• One module per endpoint. A 40-endpoint API rarely needs 40 modules. Reviewers and users both prefer a focused set plus the universal module.
• operationId names as labels. createContactV2 isn't a label. Use Make's naming conventions, for example "Create a Contact."
• No dropdowns for IDs. If users have to paste raw IDs, the app technically works but it's hard to use.
• Missing pagination. Searches that return only the first page give users incomplete data.
• Publishing too early. Public apps can't be made private again, and their components can't be deleted.
• Secrets in logs. Without sanitization in the base and connection, API keys can end up in scenario logs.

Get it built and published under your own accounts

NativeShip turns your OpenAPI spec into official, branded integrations for Make, n8n, Zapier and Activepieces. You get a Make app published from your Make account, with your logo, your company and your support email, and you review the release before anything goes public. In the live preview you can rename or hide actions before the build. Each build is checked with the platform's own tooling, and later updates pick up new endpoints without breaking existing scenarios. Our team builds and tests the app and submits it for review. Approval is always Make's decision, so we can't guarantee it.

Plans are a one-time $149 (Developer) or $349 (Startup), or we can do it all for you. See pricing. If you're also planning Zapier, read our guide to generating a Zapier integration from your OpenAPI spec. To budget for building every platform, see what an integration costs in 2026.