Skip to main content

​
1. Product Name and Icon Guidelines

1.2 The Micro app product name should relate to the brand, service scenario, and core features. The name must not exceed 5 Chinese characters, and the developer should have obtained a registered trademark for the name. 1.3 The Micro app name must not use generic, non-distinctive terms, such as CRM, ERP, Inventory Management, or Financial Software. A name combining two or more words is recommended. When the case is unclear, the reviewer may use subjective judgment to decide whether it is acceptable. 1.4 The standard size for a Micro app icon is 200*200. Irregular icons must be outlined to fit the 200*200 size. 1.5 The Micro app profile photo and logo must not contain official brand marks such as Alibaba, Taobao, Alipay, Ant Financial, DingTalk, or Alibaba Cloud (except for apps developed by Alibaba Group itself). 1.6 Any name or icon that violates national laws or regulations will be rejected.

​
2. Product Completeness Must Meet the MVP Minimum Closed Loop for the Use Case

2.1 The app must clearly meet the office or business needs of a specific core user group and must complete the minimum closed loop for that core need. 2.2 There must be one and only one main workflow. For example, for a training management product, Select Course - Arrange Study - Take Exam - View Statistics is a single main workflow. 2.3 The workflow of core scenarios must be designed as a closed loop. Any break in the core workflow will result in rejection.

​
3. Usability and Completeness of Product Feature Interactions

3.1 When submitted for review, the app must be a finished product that can be opened and run, and must not be a test version. Apps with serious bugs (such as being unable to add or open, unable to return or exit, or severe lag), that crash on their own, or that cause the DingTalk client to crash will be rejected. 3.2 When target users who are not entering the app for the first time use it, they must be able to reach the core workflow within 1-2 steps and without guidance. 3.3 Highlight the main features and main workflows. Fold less-frequently-used secondary features and branch workflows into “More” or a similar “Advanced Options” list, including optional fields in forms and secondary actions on a page. 3.4 If the app has a PC use case, a PC version must be developed at the same time. It is not allowed to provide only a web-based Micro app admin console within the OA Admin Console without a PC-side Micro app admin console. 3.5 All pages of the PC-side Micro app must open within the container, and must avoid redirecting to an external browser. 3.6 Throughout the feature experience, the product experience should be stable and healthy, and users should be able to perceive the purpose of workflow steps and page transitions. 3.7 A Micro app must consider the priority and logic of page display for users in different roles. If the product review involves different permissions, the ISV must pre-configure data in advance and prepare test accounts for different roles for the reviewer to verify. 3.8 Under non-extreme, weak-network conditions, waiting for content loading, page switching, and the like must not exceed 4 seconds at most. 3.9 If an account system is required, the app must integrate DingTalk’s silent login capability. The app is not allowed to have its own account system that requires users to enter private data such as a phone number to register and sign in. 3.10 When the app needs to use in-app payment capabilities, it must call the unified payment plugin provided by the Open Platform. The platform does not support any other form of payment. 3.11 Access to the app’s features must not require non-voluntary user actions such as forwarding, sharing, or opening other Micro apps to unlock. 3.12 Without permission or authorization from the DingTalk Open Platform, the app must not display or recommend its own or third-party apps. For example, it must not build an app center, app navigation, mutual app link promotion, or leaderboards.

​
4. Detailed Experience Requirements for Product Design and Copy Content

4.1 The product design must adopt the user’s perspective so that users with no knowledge of the product can understand it, rather than the developer’s perspective. For example, when a CRM product successfully creates a customer, it should not prompt “Database write succeeded” but rather “Customer created successfully.” 4.2 Copy should avoid confusion with DingTalk features. When using a DingTalk feature, the copy should be consistent with DingTalk’s. For example, the DING feature is written in uppercase and should not be written as Ding or ding. The Approval feature refers specifically to DingTalk Approval, and the Log feature refers specifically to DingTalk Log. 4.3 Copy should be easy to understand and avoid technical jargon used by developers. Prompts should be concise, unambiguous, and clear in reference. 4.4 Required and optional fields should be clearly distinguished. Selectable and non-selectable options should be visually distinguished. Editable and non-editable areas should be clearly distinguished. 4.5 When entering pure numbers, the numeric keyboard should be raised automatically, and when entering English, the English keyboard should be raised. Except in special cases, entering a date should call DingTalk’s standard date picker component. When the scenario is selecting a future time, times earlier than the current time should not be selectable. 4.6 When users may be unclear about what to enter, use gray text in the input field to guide the input. For input fields that are harder to understand, provide small text or a question mark icon as a hint. 4.7 When multiple form input items can be grouped into a few larger categories, clear title separations are recommended, but do not over-rely on titles for separation. Do not overuse dividers, and keep the page consistent and visually clean. 4.8 Form items at the same tier should have consistent spacing, font size, and color. Align them to the left and center them vertically. Input field widths should be as consistent as possible, and avoid placing two input fields on the same line whenever possible. 4.9 Forms should use a white background whenever possible. Form item names should use black or highly saturated gray, and avoid using red prompt text whenever possible. 4.10 Micro apps are not allowed to integrate advertising platform models such as feed ads or floating ads. Micro apps that display ads will be rejected. 4.11 Before a Micro app posts, sends, or transfers any content on behalf of a user, it must obtain the user’s explicit consent and authorization. 4.12 DingTalk advocates an equal and transparent way of working, and avoids words such as “you” (honorific) and “your esteemed company.” 4.13 The service provider of a Micro app must provide measures to filter inappropriate content. Example: Set up measures to filter and warn against words suspected of being illegal or non-compliant, such as pornography or gambling.

​
5. Care for Both New and Existing Users

5.1 DingTalk enterprise apps are generally authorized and enabled by the Admin, and the Admin also decides whether to promote their use. In the vast majority of cases, the person who first opens the product is also the Admin. Therefore, onboarding for new users, especially onboarding for the Admin, is particularly important. It must allow the Admin to experience the product’s main features quickly, without pressure, and at low cost, and to feel the product’s core value. 5.2 When a Micro app’s feature logic is complex, a dedicated onboarding flow for new users is needed. The reviewer may use subjective judgment to decide whether an onboarding flow is necessary. 5.3 Complete new-user onboarding has two aspects: basic action prompts and walking through the product’s main workflow. 5.4 Complete the product’s main workflow: Guide new users through the product’s main features, and pre-configure examples for necessary features that require substantial user input to lower the barrier to experience. 5.5 It is recommended to use methods such as overlay guidance, feature tips, and task completion so that users truly experience the product. Using images or demos for guidance is not recommended. 5.6 Rich pre-configured content, examples, and templates help users understand quickly. 5.7 It is recommended to combine the onboarding flow with product features. For example, for an intelligent customer service product, onboarding can be placed as a knowledge base in the smart chat window. For a task management product, onboarding tasks can be pre-configured as tasks that users are asked to complete. 5.8 After a product upgrade, users must be made aware of new features. 5.9 The onboarding flow must provide the ability to skip.

​
6. User Privacy and Data Security

6.1 The app must not request or induce users to enter their DingTalk username, password, or real contact information on any page. 6.2 For features that push Work Notifications to users, use “user feedback” push whenever possible. The product should avoid designing proactive push features. In special cases, this should be explained to the DingTalk team during product acceptance. 6.3 To proactively push information to authorized and enabled Organization Admins, use the push tool on the DingTalk Developer Platform. After application, the DingTalk team reviews the content and pushes it. 6.4 All rights to the data generated by enterprise customers and users in the app belong to the enterprise. 6.5 User data collected through the app must not be privately sold, transferred, traded, disclosed beyond authorization, or leaked. 6.6 When collecting and using any user data, you must clearly inform users of the purpose of the data, ensure the user’s explicit consent and authorization, and use it reasonably within the scope of the user’s consent and authorization. 6.7 After a user authorizes and enables the service, user data must not be deleted unless the user chooses to delete the data when revoking authorization. 6.8 After an enterprise unsubscribes from the service or deregisters its account, you should help the enterprise back up its data on its designated server, and then proactively delete the relevant data from services not designated by the enterprise.

​
7. Service Mechanisms Must Be Included

7.1 The app must provide a help center that pre-configures and accumulates the FAQs compiled while serving customers. 7.2 A customer service entry point must be provided within the app, and it must be a service group. No other service methods are allowed. 7.3 For app products that have already been published, all customer service and contact entry points within the app must be switched to service groups. Standalone methods such as phone numbers or DingTalk private chat QR Codes that are not service groups are not allowed. The app must be updated within one week after publication. If such non-compliant customer service paths are found during app iteration review or app inspection, the review will be rejected, and in serious cases, the app will be required to be taken down for rectification.

​
8. Differentiated Competitive Advantages

8.1 The product must have competitive highlights within its category. For example: it meets a need that other similar products do not meet, or it has a better sense of design or better interaction than similar products. 8.2 If the product itself clearly lacks competitive highlights within its category and cannot provide verifiable highlights during communication with the ISV, the review will be rejected.

​
API Integration Guidelines

​
Overview

The DingTalk App Market is committed to providing enterprise users with high-quality product services that meet a wide range of office scenario needs, deliver an excellent experience, and integrate meaningfully with DingTalk. Third-party apps must use the APIs and SDKs provided by the DingTalk Open Platform to integrate comprehensively with DingTalk, improve the user experience, ensure that enterprise information stays in sync within DingTalk, work with DingTalk to build an excellent DingTalk product ecosystem, and create apps that enterprise customers are willing to pay for. This guideline explains in detail the standards for using APIs during the development of a Third-party app.

​
Detailed Rules

Use Cases The DingTalk Open Platform provides a rich and diverse set of APIs for Third-party apps to use. The following are common use cases and user value. Developers can use APIs to integrate with DingTalk based on the scenarios within their apps.

​
Integration Requirements

First, to ensure that users can use the app conveniently and easily within DingTalk, the APIs that all apps must integrate include: silent login, Message notifications, and Contacts basic information. Second, different types of apps involve different scenarios and therefore need to use different APIs. The table below lists the minimum APIs that apps in each category must use. Developers can also integrate more Open Platform APIs during development based on the app’s category and specific scenario needs. For details, see API Call Guidelines. If the app does not involve a given scenario, you do not need to integrate that API. Please explain this during product acceptance.

​
Publication Acceptance

The App Market publication process includes an acceptance step for API integration. Through these steps, the DingTalk team can better understand how the app integrates with DingTalk, which helps both parties establish and formulate strategies for the app’s product features, user experience, and other aspects. Before submitting for product acceptance, the system automatically checks the API integration status. Please ensure that the basic APIs have been integrated and are being used by users. Otherwise, you cannot submit for product acceptance. If the app does not involve a given scenario, you do not need to integrate that API. Please explain this during product acceptance.

​
Others

If you find during development that certain APIs are not yet open, you can submit your requirements to the DingTalk team. After we receive your requirements, we will evaluate them promptly and respond.