Generate a Zapier Integration from Your OpenAPI Spec

Zapier doesn't import OpenAPI specs. Neither the Platform UI nor the Platform CLI can read one. The closest thing is the community zapier generator in OpenAPI Generator. It's in beta and produces a partial Platform CLI project: you still write authentication and search logic yourself, then test and submit through Zapier's normal review.

This guide covers where Zapier stands on OpenAPI, how to use the generator, what you have to finish by hand, and the checks your integration has to pass before it goes public.

Does Zapier support OpenAPI import?

No. Zapier gives you two tools for building on the same Developer Platform:

• Platform UI: a visual editor in the browser. Zapier recommends it if you're unsure which to pick.
• Platform CLI: a Node.js toolkit (zapier-platform) for building locally in JavaScript, with version control and custom code.

Neither one takes an OpenAPI file. A request to "import resources from an OpenAPI spec" was opened on Zapier's platform repo in 2020 (zapier-platform#187). Zapier replied, "That's currently not something we offer." One developer in the thread said 95% of their work was "copying and pasting stuff from our OpenAPI document." Zapier closed the issue in October 2025 after logging it internally, and no import has shipped.

You may see zapier-platform convert mentioned in this context. It converts an existing Platform UI integration into CLI code, and since version 17.1.0 it can also take an app definition via a --json flag (changelog). That input is Zapier's own app definition format, not OpenAPI.

Your options

Route	What you start with	What you still do
Build in Platform UI	A blank integration in the browser	Add auth, triggers, searches and actions one form at a time, copying endpoints from your spec
Build in Platform CLI	zapier-platform init scaffolds	Write every trigger, search and action in JavaScript
OpenAPI Generator zapier (beta)	A generated CLI project covering your operations	Write authentication, search detection and search response handling, fix anything the generator skipped, then test
Your own converter	Your spec and the CLI's JSON-schema helpers	Build and maintain the generator yourself

If you generate code, you're on the Platform CLI. That matters later: Zapier lets you export a UI integration to the CLI, but not the other way round. Going from CLI back to UI means a new integration version, and existing users may have to update their Zaps by hand.

Using OpenAPI Generator's zapier generator

OpenAPI Generator includes a zapier generator, which it labels BETA. It came from the team behind the Fatture in Cloud API, who used it for their own Zapier integration. A typical run looks like this:

npx @openapitools/openapi-generator-cli generate \
  -i openapi.yaml \
  -g zapier \
  -o my-zapier-integration

The output is a Platform CLI project with actions and models generated from your operations and schemas. In the generator's own words, it "generates a partial implementation of a zapier integration." Its README lists the parts you finish yourself:

1. authentication.js: written entirely by you, to match your API's auth scheme. The README suggests creating the auth in the Platform UI and copying it over, or following Zapier's CLI auth tutorial.
2. isSearchAction in utils/utils.js: returns true or false to decide which operations become Zapier searches rather than creates. The generator can't tell from the spec alone.
3. searchMiddleware in utils/utils.js: Zapier searches must return an array. If your API paginates or nests results (for example { "data": [...] }), you extract the array here.

Two more limits to plan around:

• Samples come from your spec's examples. Zapier requires a static sample for every trigger, search and action before it will publish. The generator writes samples only when your spec has real response examples, so add examples to your responses first.
• Some spec features aren't supported. The generator's feature table lists allOf, anyOf and oneOf composition, OpenID Connect security and multiple servers as unsupported. Flatten those, or expect to hand-edit the output.

A clean spec makes a big difference here. See our OpenAPI spec best practices for what to fix before generating, and if your spec doesn't exist yet, how to generate one from your code.

What the generator won't decide for you

Like Make, Zapier needs product decisions that a spec doesn't contain:

• Which operations to expose. Zapier's recommended triggers and actions by app category are a better guide than "everything in the spec."
• Triggers. OpenAPI describes requests, not events. You choose which list endpoints become polling triggers (with deduplication by id) or which webhooks become REST Hook triggers.
• Dynamic dropdowns. Zapier's checks expect ID fields to have dynamic dropdowns. That means wiring each ID field to a trigger that lists the options.
• Labels and help text. operationId values like listContactsV2 need to become "New Contact" or "Find Contact."
• Date formats. Static samples must use ISO-8601 date and time strings.

Test and validate before you publish

Run the CLI's checks locally, then push:

zapier-platform test
zapier-platform validate
zapier-platform push

Private integrations don't need to pass validation. Public ones do. These are the integration checks that most often trip up spec-generated apps:

• D004: ID fields should have dynamic dropdowns
• D007: all URLs should be HTTPS
• D009: each search requires at least one search field
• D012: a static sample is required for every trigger, search and action
• D023: dates in static samples use ISO-8601
• M007: a public integration for your app doesn't already exist
• S001: at least 3 users have a live Zap using the integration
• S002: every visible trigger, search and action has a live Zap
• T001: every visible trigger, search and action has at least one successful Zap run

S001 and S002 aren't code checks. They need real people running real Zaps, so invite teammates or beta customers to your private integration early.

Zapier's publishing requirements

Zapier's publishing requirements go beyond the code. Before submitting, make sure:

• Your app is publicly launched, not in beta, with a documented API on HTTPS production endpoints
• Users enter credentials only through the authentication config, never as fields in triggers or actions, and no keys or secrets are hard-coded
• The integration is in English
• You've given Zapier a non-expiring test account that uses integration-testing@zapier.com
• At least one admin on the integration has an email address at your app's or API's domain
• The integration doesn't move money or process financial transactions

Zapier can still decline an integration at its discretion.

Private vs public: what you get

Every Zapier integration starts private. A private integration is fine for internal use, but it has limits:

• You can invite up to 100 users by email. Public invite links have no limit, but access can't be revoked once someone accepts.
• Rate limits depend on the owner's Zapier plan: 100 calls every 60 seconds on Free and Professional, 5,000 on Team and Enterprise.
• No Zap templates, no embedding, and the app won't appear in Zapier MCP.

Going public adds the App Directory listing, Zap templates, embedding, Zapier MCP and the Partner Program. There are no fees for sharing or publishing an integration.

How Zapier review works

Per Zapier's public integration guide:

1. Open your integration's home page, choose Publish, fill in the form and click Submit for Review. If you're unsure about a requirement, Zapier suggests asking its PublishBot first.
2. A Zapier developer contacts you within a week with any outstanding requirements. Meanwhile your version shows as Pending and the integration stays Private. If it's still Pending well past that, see what to do when a Zapier review is stuck.
3. Once approved, the integration is listed in the App Directory with a Beta tag.
4. After 90 days in beta, it becomes fully public.

For every step from eligibility to public, see how to get listed in the Zapier App Directory.

Keeping it in sync with your spec

When your API changes, regenerate into a separate branch and diff against your hand-finished code instead of overwriting it. Otherwise you'll lose your auth, search middleware and dropdown wiring. Ship changes as new integration versions so existing Zaps keep working, and migrate users when you're ready.

Get it built and published under your own accounts

NativeShip turns your OpenAPI spec into official, branded integrations for Zapier, Make, n8n and Activepieces. Your Zapier integration is published from your own Zapier 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 Zaps. Our team builds and tests it and submits it for review. Approval is always Zapier'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 or browse the integrations we've shipped. Building for Make too? Read whether you can import an OpenAPI spec into a Make custom app. To compare budgets, see what a Zapier, Make, n8n or Activepieces integration costs.