---
metadata:
  - property: og:type
    content: article
  - property: article:section
    content: Plugin platform
  - property: og:title
    content: Publishing a plugin and its help
  - property: article:tag
    content: Technical instructions
  - name: generator
    content: Diplodoc Platform v5.66.1
alternate:
  - https://yandex.ru/support/tracker/en/plugins/publish.md
  - https://yandex.ru/support/tracker/ru/plugins/publish.md
  - href: https://yandex.ru/support/tracker/en/plugins/publish.md
    type: text/markdown
    title: Markdown version
  - href: https://yandex.ru/support/tracker/en/llms.txt?revision=r22077802
    rel: describedby
---
> **Documentation Index:** Fetch the complete configuration index at https://yandex.ru/support/tracker/en/llms.txt?revision=r22077802


# Preparing a plugin for publishing

Tracker users can find and enable plugins in the catalog: [How to connect a plugin from the catalog](https://yandex.ru/support/tracker/en/user/plugin-catalog.md).


Before publishing, read the [Plugin developer agreement for the Yandex 360 services plugin catalog](https://yandex.ru/legal/360_plugin_dev_agreement/ru/).


To add your developed plugin to the catalog:

1. Prepare the description and images for the plugin.

1. Prepare the help — documentation for users.

1. Submit the plugin for publishing.

After automatic moderation, the plugin will appear in the catalog of your organization with a request to enable. The organization administrator will need to approve it.

A plugin developed in your organization can be added to the public catalog so that it becomes available to users of other organizations. The publishing method depends on whether the plugin has already been published in your organization's catalog. [Publishing in the public catalog](#public-publish).

## Designing the card {#card}

Before publishing, add images and a description for the plugin card to the project:

- `public/logo.svg` — plugin logo, must be square.
- `marketplace/header-image.jpg` — image for the plugin card, must have a 2.41:1 aspect ratio. Don't repeat the plugin name in the image, as it's already shown on the page.
- `marketplace/index.md` — description for the plugin card.

### Name {#title}

- Use 3 to 32 characters.
- Write the name in Russian. Official brand and product names, such as Figma or Miro, are exceptions.
- Don't include words such as “plugin”, “widget”, or “app” in the name.
- Don't use only the name of the service that the plugin integrates with.
- Don't use a name that is more than 90% similar to the name of an existing plugin or app.
- Don't put a period at the end.

For an integration with an external service, use the “function + service” naming pattern. For example: _Sending messages to Telegram_.

### Short description {#synopsis}

The short description is displayed on the plugin card in the catalog. It should complement the name and explain the plugin's primary function.

- Write one or two sentences with a total length of up to 75 characters.
- Don't put a period at the end.

Example:

- Name: _Private notes_.
- Short description: _A private space for notes in an issue with flexible access permissions_.

### Full description {#full-description}

The full description must not exceed 4,000 characters. You can use bulleted and numbered lists. Don't add external links or advertising. Don't repeat the plugin name, as it's already shown on the page.

Recommended structure for the full description:

1. What problems the plugin solves. List its main features.
1. Who the plugin is intended for. Specify the roles or job titles of users who may find it useful.
1. How to use the plugin. Add a brief guide or usage scenario.

### Text style and tone {#text-style}

- Use a neutral, informative tone. Don't use promotional claims, superlatives, or unsubstantiated statements such as “best” or “No. 1”.
- Use letters, numbers, single spaces, and necessary punctuation marks. Don't add emoji, exclamation marks, or special characters such as `@`, `#`, `$`, `%`, `^`, `&`, or `*`.
- Don't use uppercase letters for emphasis. Acronyms of up to four letters, such as API or CRM, are allowed as exceptions.
- Don't capitalize common nouns.
- Don't abbreviate words.
- Spell brand and product names the same way as on their official websites and in their documentation.
- Use hyphens and dashes correctly. For example, _Charon — data export_ is correct, while _Charon - data export_ is incorrect.
- Use the Russian letter `ё` when omitting it could cause misreading, and in uncommon words and proper names.

## Plugin category {#category}

To make plugins easier to find, they're grouped by category in the catalog. When creating or publishing a plugin, you need to specify its categories. Categories are set in the [manifest](https://yandex.ru/support/tracker/en/plugins/common.md#manifest) in the `categories` field.

Full list of available categories:

#|
|| Slug | Name ||
|| `integrations` | Integrations ||
|| `analytics` | Analytics ||
|| `planning` | Planning ||
|| `development` | Development ||
|| `automations` | Automations ||
|| `productivity` | Productivity ||
|| `entertainment` | Entertainment ||
|| `ai-assistants` | AI assistants ||
|| `support` | Support ||
|| `security` | Security ||
|#

## Plugin help {#docs}

Help is your plugin's documentation for users. It's displayed in the plugin catalog and at the integration point in the Tracker interface.

There are two ways to provide help: host it on an external domain or include it directly in the plugin distribution package.

### External help {#external-docs}

If the documentation is already hosted on your domain, specify a link to it in the `docsUrl` field of `manifest.json`:

```json
{
    "docsUrl": "https://example.com/docs/plugin.html",
    "slots": {
        "tracker": {
            "issue.action": [
                {
                    "entrypoint": "index.html",
                    "contextLevel": "basic",
                    "title": {
                        "ru": "Мой плагин",
                        "en": "My Plugin"
                    }
                }
            ]
        }
    }
}
```

Tracker will display a link to the help in the plugin catalog and at your plugin's integration point.

### Internal help {#internal-docs}

If you want to include documentation directly in the plugin distribution package, create a `docs/` folder in the project root and place the `index.md` and `toc.yaml` files inside. The `toc.yaml` file describes the document structure:

```yaml
title: My Docs
href: index.md
items:
    - name: Introduction
      href: index.md
    - name: Getting Started
      href: getting-started.md
    - name: Reference
      href: reference.md
```

#### File structure {#file-structure}

Minimum structure for a single-page help:

```
docs/
├── toc.yaml
└── index.md
```

### Preview {#preview}

If you want to see what the documentation will look like, run the `build-docs` command and open `docs-build/index.html` in your browser.

### Publishing help {#publishing}

When [publishing the plugin](#publish), the help is automatically built with [Diplodoc](https://diplodoc.com/docs/ru/). After successful verification, the `/docs/index.html` link will be added to the plugin manifest.

{% note info %}

If the root help file is not named `index.md`, manually specify a link to it in the `docsUrl` field of the manifest. Replace `index.html` with the name of your file with the `.html` extension. For example: `"docsUrl": "/docs/my-guide.html"`.

{% endnote %}

The help is not embedded in the Tracker interface — the user follows the link, just like with external help.


## Publishing the plugin in your organization {#publish}

To submit a plugin for publishing:

1. Get a token for the CLI:

    ```bash
    weavix login
    ```

3. Run the publishing:

    ```bash
    weavix submit
    ```

    This command will automatically register the plugin if needed, upload the distribution package, and submit the version for moderation.

4. After submitting for moderation, check the publishing status:

    ```bash
    weavix list
    ```

    To view moderator comments for a plugin version, run:

    ```bash
    weavix info
    ```

    The command displays comments under the corresponding version with the author's name and date. Comments aren't displayed in the output of `weavix list`.


## Publishing in the public catalog {#public-publish}

Being public is a property of the plugin, not of a particular version. The publishing method depends on the plugin's current state.

{% note warning "Important" %}

Once a plugin becomes public, it can't be made available to your organization only again.

{% endnote %}

{% note info %}

If the CLI reports that the installed version is no longer supported, update it:

```bash
weavix upgrade
```

If the command is unavailable, reinstall the latest version: `npm i -g @weavix/cli@latest`.

{% endnote %}

### Before making a plugin public {#public-requirements}

Both `submit --public` and `make-public` check that the plugin card contains:

- `name`, `description`, `support`, `categories`, and `slug` in `manifest.json`.
- `marketplace/index.md`.
- `marketplace/header-image.jpg`.

The manifest fields are described in [Plugin description in `manifest.json`](https://yandex.ru/support/tracker/en/plugins/common.md#manifest).

Both commands also scan the archive for secrets. If the CLI finds possible secrets, fix them or select the false positives in the interactive prompt. The CLI prints a fingerprint (`fingerprint`) for each finding.

Every `make-public` run asks you to confirm the irreversible visibility change. To skip the prompt, add `--yes`. This flag is required when running without a terminal.

When running without a terminal, acknowledge the fingerprints of false positives explicitly:

```bash
weavix make-public <plugin-id> --yes --ack <fingerprint...>
```

If a non-interactive `submit --public` reports possible secrets, the plugin has already been registered. Use the plugin ID and fingerprints printed by the CLI in the command above, then submit the version with `weavix submit`.

### New or unpublished plugin {#submit-public}

Run:

```bash
weavix submit --public
```

The CLI registers the plugin, changes its visibility to `PUBLIC`, and submits the version for Yandex moderation. Once approved, the version appears in the public catalog and becomes available to users in all organizations.

If the plugin is already public, submit new versions with `weavix submit` without the `--public` flag. If the plugin has already been published in your organization's catalog, the CLI stops with an error telling you to run `make-public` instead.

You can also run `make-public` for a registered plugin that has not been published yet: it changes the visibility to `PUBLIC` immediately but doesn't submit a version. Then submit the version with `weavix submit`.

### Plugin published in an organization {#make-public}

To publish the latest version approved by your organization in the public catalog, run:

```bash
weavix make-public
```

To publish a different plugin, specify its ID:

```bash
weavix make-public <plugin-id>
```

If the plugin card is incomplete, fill in the missing data listed by the CLI. Then submit a new version with `weavix submit` and wait for your organization's approval. Finally, run `weavix make-public` again.

After the request is created, new version submissions are blocked until the moderator decides. If you run `submit` while the request is pending, the CLI reports an error and suggests withdrawing the request. To view the latest request, run:

```bash
weavix info
```

The command displays the request ID and status, version ID, request and review dates, and the moderator's comment.

#|
|| **Status** | **Description** ||
|| `PENDING` | The request is waiting for a decision. New version submissions are blocked ||
|| `APPROVED` | The request was approved and the plugin is public ||
|| `REJECTED` | The request was rejected with a comment and the plugin remains available only to the organization ||
|| `WITHDRAWN` | The developer withdrew the request ||
|| `OBSOLETE` | The request became irrelevant without a decision ||
|#

To withdraw the active request and allow version submissions again, run:

```bash
weavix withdraw --publication
```

For a different plugin, pass its ID: `weavix withdraw --publication <plugin-id>`.


## Adding to the catalog {#catalog}


After automatic moderation, the plugin will appear in your organization's catalog with a request to enable. The organization administrator will need to approve it.

Once approved by the administrator, the plugin will become available to the organization's users just like plugins from the public catalog. [How to enable a plugin](https://yandex.ru/support/tracker/en/user/plugin-catalog.md)

To make a plugin created for your organization available to all Tracker users, [publish it in the public catalog](#public-publish). Once approved by Yandex, the plugin will appear in the public catalog.