How to Publish Your App on Zapier: A Step-by-Step Guide (2026)

Publishing your app on Zapier takes four broad steps: build the integration on Zapier’s Developer Platform (using either the visual Platform UI or the CLI), test every trigger and action in live Zaps, submit it for review, then work through a 90-day public beta before your listing goes fully public.

We’ve shipped more than 15 integrations to Zapier’s marketplace for clients like Jibble, ServiceM8, Text-Em-All, and EventMobi, so this guide reflects what the process actually looks like in practice, including the parts where teams usually get stuck.

Why publish on Zapier at all

Zapier’s app directory lists 9,000+ apps, and it’s still the first place non-technical users look when they want your product to talk to their CRM, spreadsheet, or inbox. A Zapier listing is effectively a distribution channel: every “works with Zapier” search, Zap template, and app-pairing page can send signups your way.

The economics are also friendly. Building and publishing an integration is free, Zapier charges partners no usage fees, and your users pay for their own Zapier plans. Your real costs are engineering time and ongoing maintenance.

One honest caveat: an integration is a product surface, not a one-off project. APIs change, users file bugs through Zapier, and your integration health score (more on that below) affects your partner benefits. Budget for upkeep before you start.

Before you build: get your API ready

Zapier’s review team checks your API as much as your integration. The publishing requirements are explicit on a few points:

• HTTPS everywhere. Every endpoint the integration calls must use HTTPS, no exceptions.
• Production endpoints only. You can’t launch against a sandbox or staging environment.
• Your app must be publicly launched. Invite-only or beta products can’t publish a public Zapier integration.
• Public API documentation. Reviewers expect complete, current docs for the endpoints you use.
• No hard-coded credentials. Secrets live in environment variables or the Platform UI’s auth configuration.

From experience, the single biggest pre-build blocker is authentication. Zapier recommends OAuth v2 because it gives users the familiar “log in and approve” flow, with API key auth as the next-best option. If your API only supports session tokens or OAuth v1, you can still build (session auth is supported, and OAuth v1 requires the CLI), but plan extra time.

Also decide early how “new record” detection will work. Zapier triggers either poll your API (typically every 1 to 15 minutes depending on the user’s plan) or receive webhooks. REST hooks (webhook subscriptions Zapier can create and delete via your API) give users instant triggers and reduce load on your servers. If your API doesn’t support webhook subscriptions yet, adding them before you build the integration is usually worth it.

Step 1: Choose Platform UI or Platform CLI

Zapier gives you two ways to build on the same underlying platform:

• Platform UI is a browser-based visual builder. You configure auth, triggers, and actions with forms, and drop in custom JavaScript only where needed. Good for straightforward REST APIs and small teams without dedicated integration engineers.
• Platform CLI is a local Node.js development kit (zapier-platform on GitHub). You define everything in code, write unit tests, keep the project in version control, and deploy with zapier push. Better for complex auth, dynamic fields, middleware logic, and any team that wants CI and code review on their integration.

You can start in the UI and later export to the CLI, but not the other way around cleanly. Of the nearly 100 integrations we’ve published, almost all of the non-trivial ones ended up on the CLI. If your app has nested resources, custom pagination, or fields that depend on other fields, start there.

Step 2: Configure authentication

Set up your chosen auth scheme and test it with a real account. Details that trip teams up:

• Label connections clearly. Zapier lets you set a connection label (for example, the account email) so users with multiple accounts can tell them apart.
• Handle token refresh. For OAuth v2, implement refresh tokens properly. Expired-token errors are one of the most common sources of user-reported bugs after launch.
• Return a useful test endpoint. Zapier verifies credentials by calling a test request. Pick a cheap, reliable endpoint like /me.

Step 3: Build your triggers, actions, and searches

Triggers (“New Invoice”), actions (“Create Contact”), and searches (“Find Deal”) are the building blocks users see. Guidance that comes straight from review feedback we’ve received over the years:

• Follow Zapier’s naming conventions. Triggers are noun-phrases describing the event (“New Ticket”), actions are verb-first (“Create Ticket”). The publishing requirements call out proper naming explicitly, and reviewers do reject over it.
• Return sample data for every trigger. Users configure Zaps against sample records; empty or stale samples make your integration feel broken.
• Include IDs in trigger results and deduplicate. Polling triggers must return unique IDs so Zapier can tell new records from old ones.
• Write human field labels and help text. “Customer Email” beats cust_email_addr. Assume the person mapping fields has never read your API docs.
• Start with the 3 to 6 most-used workflows, not your full API surface. You can add more in later versions. A focused launch passes review faster and gives cleaner usage data.

Step 4: Test like the review team will

Before submitting, Zapier expects every trigger, action, and search to be tested in a real Zap with successful runs, and those test Zaps should stay visible in your Zap history. You also need to provide the review team a working test account for your product, created with the email integration-testing@zapier.com, and it must be non-expiring. A trial account that dies in 14 days will stall your review.

If you’re on the CLI, add unit tests too. They won’t replace live Zap testing, but they catch regressions when you push version updates later.

Step 5: Submit for review

When everything works, hit “Publish” in the Platform UI and complete the submission form. Your version moves to Pending status, and per Zapier’s public integration docs, a member of their developer team responds within a week or less with any outstanding requirements.

Common rejection reasons we’ve seen across projects:

• Branding mismatches (integration name doesn’t match your trademark, logo issues, description not following the “Integration Name is a…” format)
• Non-English user-facing text
• Auth requesting credentials outside the authentication configuration
• Triggers without dedupe-safe IDs or missing sample data
• The test account not working when the reviewer tries it

None of these are fatal. Fix, resubmit, and keep the thread with your reviewer moving.

Step 6: The 90-day beta

Once approved, your integration goes live in the app directory with a Beta tag, and beta lasts 90 days. This period is not passive waiting. Zapier expects you to:

• Publish help docs for the integration on your own site
• Create Zap templates (pre-built Zaps featuring your app paired with popular tools)
• Embed Zapier inside your product so users can discover Zaps without leaving your app
• Triage bugs and feature requests as real usage arrives

There’s a fast lane: if Zapier detects one signup coming from a Zapier embed in your product, you exit beta the next business day. Embedding is genuinely the highest-leverage thing you can do here, both for the early exit and because in-product discovery drives most long-term activation.

Step 7: Public status and the Partner Program

After beta, the tag drops and you’re a full Zapier integration partner. The Integration Partner Program has Bronze, Silver, Gold, and Platinum tiers based on your integration’s active users and health score, evaluated quarterly. Per Zapier’s current thresholds, Silver starts at 50 active users, Gold at 350, and Platinum at 3,000 (or 350 with 20% quarter-over-quarter growth). Higher tiers unlock additional partner benefits, so it’s worth reviewing the current tier list on Zapier’s site as thresholds and perks change over time.

Your integration health score matters here. Unresolved bugs and stale versions drag it down, which is another reason to treat the integration as a living product.

(Side note on terminology: this Integration Partner Program is separate from Zapier’s Solution Partner Program for consultancies, which also runs Silver, Gold, and Platinum tiers. GolmTech is a Platinum Solution Partner, the highest tier, which is how we ended up building marketplace integrations for other companies in the first place.)

Build it yourself or bring in help?

If you have a Node.js-comfortable engineer, a clean REST API with OAuth v2, and modest requirements, budget roughly 2 to 4 weeks of part-time work to reach submission. It’s very doable in-house.

Consider outside help when your API needs webhook subscriptions built first, your auth is non-standard, you have dynamic or dependent fields, or nobody internally can own post-launch maintenance. That’s the work we do on our Zapier app development service, from scoping triggers and actions through review, beta, and ongoing version updates. We work in fixed-price projects (starting at a $2,500 minimum), with optional care plans for teams that want the maintenance handled too. If you want to talk through whether your API is ready, book a call.

FAQ

How much does it cost to publish an app on Zapier?

Zapier charges nothing. Building and publishing an integration is free, there are no partner usage fees, and your users pay for their own Zapier plans. Your real cost is development time: typically 2 to 4 weeks of engineering for a straightforward REST API, more if you need to add webhook subscriptions or handle unusual authentication first, plus ongoing maintenance as your API evolves.

How long does Zapier’s app review take?

Zapier says a developer will respond within one week or less of submission with any outstanding requirements. Total time to approval depends on how many review rounds you need. Clean submissions that follow the publishing requirements often clear in one or two rounds; integrations with naming, auth, or test-account issues can stretch to several weeks of back-and-forth.

Should I use the Platform UI or the CLI?

Use the Platform UI for simple REST APIs and small trigger/action sets; it’s faster to learn and requires no local setup. Use the Platform CLI when you need version control, unit tests, OAuth v1, dynamic fields, or complex request logic. You can migrate from UI to CLI later, so starting simple isn’t a dead end. Most of our non-trivial client integrations live on the CLI.

How do I get out of the 90-day beta faster?

Embed Zapier inside your product. Per Zapier’s docs, once a single Zapier signup is detected coming from your embedded implementation, your integration exits beta the next business day. Embedding also drives long-term adoption, since users discover and turn on Zaps without leaving your app, which feeds the active-user counts that unlock higher partner tiers.

What happens if my submission is rejected?

Nothing permanent. The reviewer sends specific outstanding requirements, you fix them, and you resubmit. Common fixes include renaming triggers and actions to match conventions, correcting the app description format, adding sample data, and repairing the integration-testing@zapier.com test account. Avoid repeatedly resubmitting an unchanged integration, which the publishing requirements explicitly flag, but a normal fix-and-resubmit cycle is expected.

Can I update my integration after it’s public?

Yes, and you should. Zapier versions integrations: you create a new version, test it, then promote it and migrate users over. Breaking changes (renamed fields, changed auth) need care because existing Zaps depend on your current structure. This ongoing versioning work is most of what integration maintenance actually is, and it directly affects the health score that determines your partner tier.