App submission process

Learn about Kustomer's manual review process for applications.

In order for your application to be published to the Kustomer App Directory, it must undergo a review from our app development team. In this article, we'll cover the app submission process, what you can expect during a review, and how to best prepare your app for a quick approval.

Submitting an app

Please use this Google Form to submit an app for review.

In the form, you will upload your app assets and fill out a questionnaire. Keep reading this document to learn what to expect during submission.

A member of our app development team will process and review your submission and will let you know within 1-2 weeks.

App format

The app should be submitted as a single JSON file.

Asset requirements

Screenshots
Format: .jpg

Use best judgment and test how the screenshots appear on various screen sizes. We might ask you to provide improved screenshots if they appear too large or too small on typical desktop or laptop-sized displays.

Screenshots should show only the actual app itself and not logos, graphics, text or collages.

Logo / Icon
See: App logo requirements

If your app is accepted

If the app submission is approved, we'll deploy your app to the Kustomer App Directory.

To schedule an app release with a specific date, please note this request in the app submission. By default, we will release the app to the App Directory shortly after a successful review.

If your app is rejected

During our review, we may encounter an issue with your app submission that you'll need to address before the app can be published. If this occurs, our team will respond via email with more information about why the app was rejected. This email will include actionable feedback that lists everything that's either missing, incomplete, or unacceptable.

App submission checklist

Planning your app

  • Apps need to be fully tested before submission.
  • Do not submit beta versions of apps. Beta testing must be done with private apps.
  • App submissions should be final versions, and cannot include any placeholder content.
  • All app information provided in submission and app definition metadata should be complete, accurate, and up-to-date.
  • Do not include any hidden or undocumented features in your app. App functionality must be clear to end-users and the app review team.
  • Optimize your app to effectively use its available resources. Apps that would cause high computation or storage costs without adequate reason are likely to be rejected.
  • Apps should not require the user to manually configure their Kustomer instance beyond filling out your app's settings.
  • Apps may not install additional app components by calling Kustomer's API. All installed components must be declared in the app definition.

Apps that integrate with external platforms

  • Provide credentials for an active demo account so we can test your integration.
  • Ensure that all external APIs the app integrates with are online and accepting requests by the time you submit.
  • Apps should not require the user to manually configure an external system for the app to function. (For example, requiring the user to generate an API key and store it in an external platform is scoped incorrectly, as this can be avoided by having the app use Kustomer's OAuth 2.0 Provider.) If external configuration is necessary for the integration to work, it does not fit our definition of an app.

After submitting

  • Keep your contact information up-to-date after the submission process in case we need to contact you.

App directory description

Refer to our App content guidelines.

If your app requires an external subscription, this should be noted in the app description with links to pricing information.

Include detailed setup and usage instructions, especially for features that might not be obvious to all audiences.

If the app sends data to a third party system, the app description must highlight what type of data it sends, when it does so (e.g. triggered by a certain event), for what purpose, and what happens to the data on the other end. Apps whose descriptions lack this information will be rejected.

Release notes

Changes to your app with each update should be documented in the form of release notes. The Kustomer app development team expects you to be able to tell users what's new or changed in each update. This should be similar to what your team already provides when developing for other platforms like the Apple App Store.

Customers often postpone installing app updates if they lack confidence around what's changing, and whether the update will disrupt their live businesses. Lack of clarity in the update process can result in an organization putting off installing a crucial upgrade, resulting in issues and downtime.

You can mitigate this by using release notes to provide a thorough, easily-understandable changelog that tells users about new features and functionality, bugs that were fixed, and any other relevant changes.

Provide a bulleted list and be specific about changes in release notes. Avoid vague or repetitive statements like "We are always improving our app with with fixes and updates."

When outlining changes to your app, we recommend you frame the conversation around user value. View your release notes from the perspective of a user seeing your app for the first time in our app directory: Why should this audience be interested in your latest changes? How is their experience with your app made better with this update?

For example, this release note accurately describes a change to the app, but the framing is focused on a potentially internal name for a change with vague user value:

The release note can be improved by refocusing the message in terms of how the user experience benefits from this change:

👍

Example Release Notes:

What's New

  • Calendar Widget
    • We've added a calendar view to the Insight Card that allows agents to see a customer's upcoming appointments.
  • Keyboard Shortcuts
    • SuperApp now supports keyboard-based navigation and shortcuts for agents in the timeline.
    • Users on Mac and PC can create cases, find issues, and link conversations using modifier keys.
    • See our updated documentation for the full list of shortcuts.
  • Bug Fixes
    • Fixed an issue that could cause text entered after a URL to be appended to the hyperlink instead of added as plain text.
    • Changes to the Loyalty attribute are now immediately displayed in the Insight Card.

Data security and compliance checklist

In order to approve your app, our team will need to understand your company and app's data security and compliance practices.

You will need to answer the following questions in the Google Form for initial app submission and major app updates:

Privacy and data governance

  • Where can users find your terms of service?
  • What is your data retention policy?
  • What is your data archiving and removal policy?
  • What is your data storage policy?
  • Where are your data center(s) located?
  • How is your data hosted?
  • What is your data hosting company?
  • Does your app/service have sub-processors?

Certifications and compliance

  • What security policies and certification standards do you comply with?
    • SOC attestation, ISO/IEC certifications, CSA Star level, etc
  • Where can users find your privacy policy?
  • What is your GDPR policy?
  • What are your data deletion request procedures?
  • Do you offer HIPAA compliance?

Security

  • Which providers do you support Single Sign On (SSO) with?
  • Do you support Security Assertion Markup Language (SAML)?
  • Do you have a dedicated security team?
  • What is your contact information for security issues?
  • Do you have a vulnerability disclosure program? Where can users find it?
  • Does your vulnerability disclosure program include your Kustomer app?
  • Do you offer a bug bounty program? Where can users find it?
  • Does your app require third-party authorization or connections?
  • Does your app use token rotation?

App versioning schema

Version updates to your app must adhere to the principles of semantic versioning. The app submission and review process differs depending on whether the app version is a major, minor, or patch version update.

When submitting a new app version, the app description should list the new features and changes. While we don't require you to maintain a detailed changelog in the app description, important updates across all versions needs to be captured.

Once an app is approved and posted to our App Directory, subsequent bug fix reviews will be prioritized in our review queue.

Major - Initial app registration (v1.0.0)

The first time you submit an app to our developer team. It should include full documentation and data/privacy disclosure.

Example: Version 1.0 is our debut on the app directory.

Major - Version upgrades with breaking changes (v2.0.0)

Significant new versions of your app that contain major changes to the app or UI that offer new functionality. Submit as a major version upgrade if the update will include any breaking changes that would require an admin to perform additional work to reimplement the app after updating. This includes reconfiguring the app or app-installed features, setup of new app settings, migrating data, etc.

When publishing a major update, we ask that you review your data/privacy practices and note any changes related to your new functionality.

Example: Version 2.0 introduces two-way sync with Shopify that needs to be set up in Settings.

Minor - (v1.1.0, v1.2.0, v1.3.0, etc)

Small updates that add minor functionality. Minor updates can include bug fixes alongside new features and other improvements.

Minor updates do not require updating your data/privacy questionnaire, but if there are relevant changes you need to note please include this in your submission.

Example: Version 1.2 adds a tab in the Insight Card where agents can now search for orders. No additional admin configuration is required.

Patch - (v1.0.1, v1.0.2, v1.1.4, etc)

Smaller updates with patches and bug fixes that are limited in scope.

Patch updates do not require updating your data/privacy questionnaire, but if there are relevant changes you need to note please include this in your submission.

Example: Version 1.1 resolves a bug that caused layout issues at some screen sizes, and improves the sort order of search results.

Patch (Critical Bugfix)

Critical updates that require an expedited review process.

Critical patch updates do not require updating your data/privacy questionnaire, but if there are relevant changes you need to note please include this in your submission.

Example: Version 1.2 resolves a bug that prevented orders from loading.

📘

On our roadmap: Auto-updating apps

Our team is exploring ways to offer auto-installation of app updates in the future, which would allow organizations to stay up-to-date with the latest version of your app whenever you put out a minor update or patch. This page will be updated when this functionality is available.

In the interim, if your team has feedback or comments about this potential functionality, please reach out to us at [email protected].


What’s Next

As you plan development of your app, please review and adhere to our Design Guidelines.

Did this page help you?