Standards for Quality Content

All listings on the Marketplace should meet the following general guidelines:

Guidelines	Details
High Reusability	When creating connectors, keep in mind that it should be highly reusable in the sense that it can be used in multiple processes and can be easily adapted to different cases, by a large number of users. It is important to ask for user input in places where integration specific values are needed and not to include unnecessary values that are specific to a particular build. Common areas for user input variables include Authentication (API Key, subdomain, Client ID/Client Secret) Path parameters (Base URL or resource path) Parameters and request fields (Do not provide default values that are specific to one build)
Completeness	The connector should enable solving the target use case for an end-user. The listing should cover what use-cases and functionalities of the connector are implemented.
Originality	It is important not to duplicate functionalities of connectors already available in the official UiPath catalog. Please do reach out to us if you want to suggest improvements or extend the functionality of a connector that is already available in our official catalog.

Important:

For a listing to be published on UiPath Marketplace, you must include in the listing's Description all details about the capabilities that the connector provides & any information on compatibility with target systems.

Partners may not include the names of third parties or third parties' apps or other third party products in the text of their listing or product description on the UiPath Marketplace without express authorization from the third party.

Standards for Connectors

All checks below need to be addressed in the Connector package metadata before submitting it on the Marketplace:

• ID/ Package name convention:

  • The package name should clearly identify the vendor/system for which you are building the connector.

• Descriptions should be specified for the following:

  • Connector

  • Activities

  • Fields

• Ensure that you choose the relevant category under which the connector should be published.

• Relevant tags are added.

• License URL and License acceptance checkbox are specified based on the license type selected.

• The owner of the package is mentioned. Company name needs to be added in case of publishing on behalf of the Company.

• The Icon should be that of the vendor for which you are building the connector or an appropriate image that help users identify for which vendor/system the connector is for. Please do not use images you do not own the right for.

• Language is specified, even if the field is marked as Optional.

• The connector’s compatibility with vendor system is clearly listed (e.g. which vendor system versions are supported, limitations etc.).

• Activities have unique names within a connector to make them easier to debug.

• Check for corner cases​ that might happen during execution.

• Check for performance​ bottlenecks.

• Check for optimization opportunities​.

• Passwords or sensitive information should not be exposed or recorded by the connector. No authentication values that differ per connection should be stored in the authentication configuration.

• Connectors with OAuth 2.0 should always be BYOA (i.e. bring your own authentication where the user/customer configures OAuth 2.0 app & provides the necessary parameters such as client ID, client secret etc.).

• For connectors using OAuth 2.0, do not hard code client ID & client secret as part of the connector package.

• Ensure the following aspects are followed for Activities and fields:

  • Activity Title / DisplayName should always be Title Case (E.g Send Message to Channel)
  • Activity Description should always be Sentence Case (E.g. Send a message to an individual user)
  • Field Title / DisplayName should always be Sentence Case (E.g. Bot icon)
  • Activity Description should always be Sentence Case (E.g. Bot icon)
  • Categories of connectors should be in Sentence Case (E.g.Artificial intelligence)

• Avoid hard-coding base URLs which are susceptible to change (e.g. base URL contains version of vendor system).

• Ensure ENUMS are added with user readable display names / descriptions (using Enhanced Enums).

• Ensure proper data types are set to fields across activities. Avoid unnecessary transformation/conversion of data types within the connector.

• For Triggers, make sure to have meaningful Event Data Filters. For example, do not add fields like IDs, GUIDs etc. which cannot be used for filtering.