Skip to main content

Get Support
Have a question? Let's get you an answer!

How Do I...? Troubleshooting Code & Webhooks Developer Zone

Other Help Resources
Wait, there's more! Check out these Community sourced spaces for additional resources.

Zapier Help Center Hire an Expert

Learning Resources
All of our best learning resources can be found here.

Featured Articles Show & Tell Zapier's products AI Hub Zapier Tools Hub

Share your knowledge
Give back to the Community by sharing your automation wins and helping to answer questions.

Share your success See unanswered questions User Groups

Other Learning Resources
Some of our favorite additional ways to upskill your Zapier knowledge.

Zapier Learn Zapier Blog Zapier Webinars

Product Updates
Check out what is new and upcoming with Zapier with our regular product updates.

Product Updates

Early Access Program
Want to join Early Access? Learn more here.

Hello,

I’ve been developing a Zapier Integration via the CLI over the past few weeks and we are getting close to submitting the Integration for review. As such I’m currently in the process of going over the Zapier Integration Review Guidelines and making sure that my team has completed all of the necessary steps prior to publishing. However, these guidelines state that prior to publishing we must:

ensure all integration information and metadata is complete and accurate. Be sure to follow Zapier's standards for integration branding

 

I’m not fully understanding where I can submit this information prior to submitting the Integration for review? When on the Integration development homepage, after clicking “Publish” the only App Details that I can enter are as follows:

 

 

Do we need to add the information described in the Branding Guidelines prior to submission? And if so how can this be done when the Integration is developed via the CLI?

You’ll prepare your submission for publishing review in the UI, even if you’re developing with the CLI. 

Then go to https://developer.zapier.com/ and select your integration.

You’ll set up your logo, name, home page link, and other essential details in settings https://developer.zapier.com/app/{yourappid}/version/1.0.0/settings

Additional information needed by Zapier to support and begin to promote your integration will be requested when you select “Publish”, which routes you to https://developer.zapier.com/app/{yourappid}/publishing

There’s a number of other managing and monitoring facilities in the UI. Spend some time checking it out. You’ll want to check the UI for bug and feature requests that Zapier support will be passing along from your users once your integration is published.

All fields marked required are, in fact, required. 

Let us know if you have any other questions or run into blockers along the way.

Thanks Zane, that really helped clarify things. What about “Zap Templates”, are these required to be built prior to submitting the Integration for publication? I tried creating a Zap Template for my Integration but I could not find my Integration in the search results for available Triggers. Is this because my Integration is still ‘invite only’?

You’ll prepare your submission for publishing review in the UI, even if you’re developing with the CLI. 

Then go to https://developer.zapier.com/ and select your integration.

You’ll set up your logo, name, home page link, and other essential details in settings https://developer.zapier.com/app/{yourappid}/version/1.0.0/settings

Additional information needed by Zapier to support and begin to promote your integration will be requested when you select “Publish”, which routes you to https://developer.zapier.com/app/{yourappid}/publishing

There’s a number of other managing and monitoring facilities in the UI. Spend some time checking it out. You’ll want to check the UI for bug and feature requests that Zapier support will be passing along from your users once your integration is published.

All fields marked required are, in fact, required. 

Let us know if you have any other questions or run into blockers along the way.

 

Thanks Zane, that really helped clarify things. What about “Zap Templates”, are these required to be built prior to submitting the Integration for publication? I tried creating a Zap Template for my Integration but I could not find my Integration in the search results for available Triggers. Is this because my Integration is still ‘invite only’?

hi
@Zane I hope you are good.
can you please help me to understand this?
Do We need 3 (invited users) with all events of active zaps to go Public? For example This is condition or I’ve to invite more users 5-10.

can you please explain these points.

1- Number of users?
2- All users should have active zaps of all triggers?

The pre-publish validation rule is based on unique users with enabled Zaps. https://platform.zapier.com/docs/integration-checks-reference#s001---3-users-with-a-live-zap

This means you need 3 users testing. They need all need to have one Zap that’s not paused. They don’t need to have an enabled Zap for each trigger and action. But it’s expected that you have good test coverage for each through some mechanism.

 

For the earlier question about Zap Templates and trying to do that before you get your integration through review and published:

You'll need to have a published integration before you can construct templates. So, Zap Templates are not a requirement to request initial publishing of the integration itself.

Getting ZTs created is a requirement of "launching" - getting an official designation as a Zapier partner. ZTs will likely help you get to 50 active users quicker, which is another milestone they look for, so I suggest getting them published sooner rather than later!

I see that we’ve to provide API Documentation URL 
@Zane can you please help me to understand this, either I’ve to include simple doc or It should be like Swagger type doc where all type of form and documentation included?

The purpose of the API doc link is to help Zapier Customer Champions.  Often they get tickets from our partners’ users and end up troubleshooting network logs. Having API documentation available internally for them helps they understand what your API is meant to be doing, and to help them understand what they’re seeing when stuff is going wrong - so that they can pass on specific and validated information to your engineering team.

So good OpenAPI specs are perfect. And/or anything else that helps our team with detailed troubleshooting later. 

hey @Zane can you please provide some sample screenshot / URL? 

Terms & Conditions