Before you can submit your integration for publishing, it runs through a set of automated checks to ensure it’s working properly and giving our users (and yours) the best possible experience.
Run Validation
from the Version Overview tab in the Platform UI or run the zapier validate
command in the Platform CLI to be notified of any issues and recommendations to better the user experience.
To help better address a check in communication, each check is given a unique ID, consisting of a capital letter and three digits, such as D001
.
You don’t need to know the implication of the initial capitial letter. But if you’re curious, they are:
Area | Description |
---|---|
Connected Accounts | Connected accounts that are linked to your integration. We verify these to ensure the authentication is working. |
Compatibility | Only apply when your integration is public, these checks verify how the new version is backward compatible with the currently public version. They ask questions like “would this change break existing Zaps, Zap Templates, or connected accounts?” |
Definition | Definition of the integration, including auth and trigger/search/action configurations. Some of these checks could block you from saving/pushing if the violation results in a broken trigger/search/action. |
Environment Variables | Integration environment variables may impact the runtime behavior of your integration versions. These checks may prompt you for confirmation before performing actions like migrating or promoting. |
Lifecycle | The lifecycle state of your integration or its versions, such as the visibility (private, pending, or public) and the version state (deprecated, non-production, or production). |
Marketing | Public-facing information, such as the app title, description, and logo. The intent of these rules is to give Zapier users a consistent style among texts and images across all public integrations. They’re more likely to block you from going public. |
Stats | Usage stats, such as the number of users your integration has. These are more likely to block you from going public. |
T - Zap History | Data from runs in your Zap History, produced by live (enabled) Zaps. These are more likely to block you from going public. The “T” checks are named as such for historical reasons. Zapier now shows tasks in the Zap History. |
User | Things in the developer’s (your) account, such as Terms of Service acceptance. |
Zap | Things related to Zaps, such as the trigger samples you pulled into the Zap editor. |
key
property of an input_field
, Zap Templates that use that field become invalid. Try to avoid this when you can.
key
property of an item in your sample
, Zap Templates that use that field become invalid. Try to avoid this when you can.
id
into Zapier,
providing them with a dynamic dropdown
greatly increases the likelihood of the user setting up Zaps correctly. Users will
still be able to map custom fields, but this gets them started on the right foot.
Read more about implementing dynamic dropdowns below:
performList
) operation fetches a
(real) recent message using the provided URL for polling and uses it as the test result.
The polling URL in a REST Hook trigger is only used for testing during a Zap setup.
It’s very important that the structure of an object from a webhook and from a poll
are identical. Typically, this means modifying a poll result so that it looks like a
hook. If a poll has fields that a hook doesn’t, the user may map them to a later
step, and when the Zap runs live, the value will be blank. This can cause errors
or unexpected results for users.
Let’s walk through an example. Say we have a New Contact
REST Hook trigger. When a
new contact is created, Zapier gets a webhook that looks like this:
https://site.com/contacts/list
and return:
friends
information, and return only the array of contacts, not the
enclosing object.
The polling result is not used when a user skips testing the Zap step. In that case,
Zapier uses the sample data.
See Sample Data for more details on
this.
primary
, the deduper will by default use the id
field as the primary key.
Hooks are not deduped, so they’re not required to have a primary key.
This check ensures the static samples in your integration definition contain the
primary key fields. It’s similar to T002
. The difference is that T002
validates
the live polling results in the Zap History.
an example of an incorrect implementation:
searchOrCreates
must reference to an
existing search or action. Otherwise, it won’t work.
Triggers when
and end with a .
.
examples of an incorrect implementation:
T003
. This check validates the static samples in
your integration definition, while T003
validates the live results
in the Zap History.
examples of an incorrect implementation:
https://developer.zapier.com/app/APP_ID/version/APP_VERSION/settings
.
Collaborator team members with the same domain as the homepage do not meet this
requirement.
https://developer.zapier.com/app/APP_ID/version/APP_VERSION/settings
.
primary
, the deduper will by default use the id
field as the primary key.
Hooks are not deduped, so they’re not required to have a primary key.
This check ensures the live polling results in the Zap History
contain the primary key fields. It’s similar to D010
. The difference is that
D010
validates the static samples in your integration definition.
This check is performed using the Zap History for
accounts belonging to the integration admins, so build your test Zaps in these
accounts.
examples of an incorrect implementation:
D023
. This check validates the data in the
Zap History, while D023
validates
the static samples in your integration definition.
This check is performed using the Zap History for
accounts belonging to the integration admins, so build your test Zaps in these
accounts.
examples of an incorrect implementation:
Perform List
URL (check
D006
) so that users can retrieve a real data sample in the Zap editor. This is
called a polling sample, and is created when you test the trigger in the Zap editor
before turning it on.
Errors occur when a Zap uses a field from the polling sample that is not
provided by the hook payload sent once the Zap is running.
To ensure this doesn’t happen, this check compares the latest item in the
Zap History with the selected polling sample in
the corresponding Zap. For it to pass:
Perform List
URL (check
D006
) so that users can pull a live sample in the Zap editor. This is called a
polling sample.
This check takes the latest polling sample from a Zap with this trigger
and verifies that the sample conforms to the output fields for the
trigger in your integration (if defined). The specific checks are: