Validate the app before publishing

There is a list of checks that needs to be run to ensure your App is working properly and giving users the best possible experience.

Before you start

You should have a configured app.

How it works

Each validation code is given a unique ID, consisting of a capital letter and three digits eg: D001.

Following are the validations that needs to be tested:

1. A001(A Connected Account Exists): To ensure you’ve tested auth, we require you to set up at least one connected account.

2. D001 (Asks for API Key in Action Instead of in Auth): Some integrations incorrectly have api_key or similar as an an action field in an action instead of centrally used in auth. Additionally, the ability to test the validity of auth doesn’t exist for action fields, so anything auth related should be put into an auth field instead.

3. D002(Provide Link in Help Text for Auth Fields): It’s often not obvious where a user can find their API credentials for a service. If you use a pasted API key as an authentication method, it’s strongly encouraged that you link the user to the page (or relevant help doc) that has their key.

4. D003(Connection Label Should Be Set): Connection Labels help customers understand and remember which account they connected for a given Connected Account. These should be short and something easily identifiable.

5. D004(ID Fields Should Have Dynamic Dropdowns): We’ve found that instead of instructing users to paste an item id into Eshopbox, 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.

6. D005(Dynamic Dropdown Connects to a Non-Existing Trigger): Dynamic dropdowns allow you to connect an input field to an existing trigger. The dropdown won’t work if the trigger key you specify doesn’t exist.

7. D006(REST Hook Trigger Needs a Polling URL): When users are setting up a hook-based (aka instant) Trigger, it’s important to have a polling fallback. 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 is run for real, the value will be blank.

8. D007(All URLs Should Be HTTPS): When handling customer data it’s strongly encouraged that all communication take securely. Using SSL is a big part of that, so ensure your URLs have HTTPS as their protocol.

9. D008(Invalid Markdown Link): A valid markdown link consists of a pair of square brackets with the link text paired with a pair of parens that have the link itself.
   If you want to show a full link without actually linking to it, use backticks. This makes it clear to the user that they don’t need to click the link, it’s just used as an example. Any link used in plain text needs to either be a proper link or in backticks.

10. D009(Requires at Least One Search Field): When making a search step, it’s important to have a field to search on! Common examples for searching for a user are by name, email, and username.

11. D010(Missing “ID” Field in Static Sample Data): For polling triggers, the deduper uses the id field to decide if it’s seen an object before. It can be any sort of string, but it’s important that it’s unique. If your object is returned with a differently named id field (such as contact_id), write code to rename it. Hooks are not deduped, so they’re not required to have an id.

12. D011(Redundant Help Text): Help text is optional and meant to provide non-obvious information or links for the user. If the label and help text are the same, they are considered redundant.

13. D012(Static Sample Is Required): When a user sets up a trigger, they need sample data to be returned in order to have fields available to map in the subsequent steps. If testing the trigger returns no live results, we use static sample data as a fallback.

    It’s very important that the structure of an object from the actual trigger and in the sample data are identical. Otherwise, users could map fields that don’t exist in the live results, which results in a broken Zap.

14. D013(Connects to a Non-Existing Search): Search-Powered Fields prompt users to set up a search step to populate the value of the field. It won’t work if the search key you specify doesn’t exist.

15. D014(Has a Search Connector, but No Dynamic Dropdown): By design, to get the “Add a Search Step” button, an action needs both a search connector and a (valid) dynamic dropdown. If you can’t provide a valid dropdown, you can instead point to a dummy trigger that always returns an empty array.

16. D015(Search-Or-Create Connects to a Non-Existing Action/Search): The search or create key you specify in searchOrCreates must reference to an existing search or action. Otherwise, it won’t work.

17. D016(Consists Only a Static Webhook): Static Webhooks, while convenient to build, leave a lot to be desired from our side. For this reason, Eshopbox doesn’t allow integration that are a single static hook. To fix this, add more triggers/searches/actions.

18. D017(Static Hook Is Discouraged): As static webhooks are a little more complicated to set up correctly, we discourage their use. We no longer support adding new static webhook triggers to a public integration, please use an alternative trigger type, such as REST Hook or Polling.

19. D018(Titlecased Label): In order to have a consistent style across trigger/action/search labels, they’re required to be presented in title case. If you fail this check, a passing version of your label will be shown.

20. D019(Too Few Important Triggers/Searches/Actions): In order to highlight your most popular steps and give the user a clear recommendation of what to use Eshopbox for, we encourage the use of “important” steps. Important steps are shown first in the UI, while non-important steps are shown after a “show more” click.

21. D020(Too Many Important Triggers/Searches/Actions): In order to highlight your most popular steps and give the user a clear recommendation of what to use Eshopbox for, we encourage a limited number of “important” steps. These are shown first in the UI and aren’t behind a “show more” click.

22. D021(Trigger Description Requirements): Trigger descriptions must start with Triggers when and end with a ..

23. D022(Creates Should Try to Have Static Input Fields): When making Zap Templates, it’s helpful to have input fields that are common for all users. Without any, it’s hard to create templates. If possible, add some static input fields that all users will be able to use.

24. D023(ISO-8601 Date/Time Format in Static Sample): To ensure Eshopbox can correctly parse dates and times, you should always use ISO-8601 format to represent dates or times. Timezone info should also be present if it contains time.

25. D024(Static Sample Respects Output Field Definition): If you define output fields for a trigger/action/search, they should be consistent with the static sample data. The specific checks are:

    • “required” fields must be in the sample

    • field values in the sample match their field type

26. L001(Version Is Deprecated): You can’t promote a deprecated version.

27. L002(Integration Is Pending): This could happen if you’re repeatedly submitting an integration that is already pending for review.

28. L003(Version Is Already Production): This could happen if you’re promoting a version that is already production.

29. M001(App Category Is Required): To correctly categorize your integration on Eshoopbox, please choose the category that fits best your app. You can specify a category for your integration in the Integration Settings page.

30. M002(Description Is Invalid): Your app’s description is a place to talk about your app.  it’s discouraged that you talk about how this integration will sync anything, as the space is supposed to be about your service itself instead of the Eshopbox integration in particular. Lastly, this section should have 1 - 3 sentences or at least 40 characters.

31. M003(Invalid Logo): Your app’s logo will be used all over the site in square containers and in various sizes. To ensure it looks good at all sizes, the logo image must be:

    • a square PNG image

    • at least 256px by 256px in size

    • in RGBA mode so it can have a transparent background

32. M004(Homepage URL Must Be Present): Each app must have a homepage URL.

33. M005(Public Integration Already Exists): We only allow one public integration in our app directory for a given app. If a public integration with the same title already exists, we probably won’t approve your submission to go public. If you’re the owner of the existing public integration, you may want to create a version and promote that instead of submitting a new integration.

34. S001(3 Users with a live Zap): To verify user demand, there should be at least 3 users who have a live Zap using this integration. “Live” means at least one successful task in recent history.

35. S002(One Live Zap for Each Trigger/Search/Action): To ensure any show-stopping bugs are worked out, every visible trigger/search/action of your integration should have a live Zap that demonstrates it works.

36. S003(Live Version Count Limit): You can’t have more than 5 (former and current) production versions with users that have active Zaps using it. To continue, you should migrate users over to a new version so you can delete the unwanted versions.

37. T001(One Successful Task for Each Trigger/Search/Action): To ensure you have tested every visible trigger/search/action, there should be at least one successful task in at least one of the integration admin’s task histories for each visible trigger/search/action.

38. U001(Developer Terms of Service): You must agree to the Developer Terms of Service in order to proceed.

39. Z001(Polling Sample Respects Output Field Definition): For hook triggers, we require you to provide a Perform List URL 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 one of the integration admins’ Zaps and verifies if the sample conforms to the output fields if you defined them for your integration. The specific checks are:

    • “required” fields must be in the polling sample

    • field values in the trigger result match their field type

Related Articles

https://auperator.atlassian.net/wiki/spaces/IO/pages/929596477

https://auperator.atlassian.net/wiki/spaces/IO/pages/937492605