Submit a plugin via the personal cabinet

The community marketplace lets any registered customer publish a plugin for everyone to install — the same way you publish an app to an app store. You fill in store-page metadata, declare what permissions your plugin needs, upload the build, and send it for review. This page walks through the whole thing step by step.

[!NOTE] This flow is for community (third-party) plugins submitted through your personal cabinet at my.aihummer.ru. First-party AiHummer plugins ship on their own pipeline. Community plugins are free; you may add an optional donation link.

Before you start

A registered personal-cabinet account — sign up and confirm it (see Registration). Any customer may submit.
A built plugin — a signed release tarball produced with the Plugin SDK (aihummer plugin package). If you have not built one yet, start there first.
An icon and at least one screenshot, and your descriptions ready in both Russian and English.

How publication works (the big picture)

Your submission moves through a fixed pipeline. You can watch its status in the cabinet at every step.

Stage	What happens	Who acts
Draft	You create the entry and fill metadata; nothing is public yet.	You
Submitted	You send it for review.	You
AI review	An automated agent checks the plugin against the review policy — security, manifest correctness, completeness, content.	Automation
Moderation	A human moderator reads the AI report plus your artifact and metadata and decides.	AiHummer team
Published	On approval the artifact is signed and added to the community catalog + the public marketplace feed.	AiHummer team
Rejected	If something fails, you get the reasons; fix and resubmit.	You → back to Draft

[!IMPORTANT] The AI never publishes on its own. A human always makes the final decision, and nothing reaches the catalog without their approval.

Step 1 — Open «My plugins»

Log in to my.aihummer.ru, open the «My plugins» section, and click «Publish» (or «New plugin»). This creates a draft you can edit freely until you submit it.

Step 2 — Fill the store metadata

Fill every field. Incomplete metadata is one of the most common reasons a submission bounces back.

Field	What to enter
Name (RU + EN)	The plugin’s display name in both languages.
Short description (RU + EN)	One line for the catalog card.
Full description (RU + EN)	What the plugin does, how to use it, what it needs. Meaningful — not a placeholder.
Category	Pick one from the allowed set (e.g. Channels, Productivity, Integrations, Voice, Utilities).
Version	A semver string, e.g. `1.0.0`. Each new submission must increment it.
Icon	A valid square image.
Screenshots	At least one; showing the plugin in action.
License	The plugin’s license (e.g. MIT, Apache-2.0).
Homepage / repository	Optional `https://` link to your project.
Donation link	Optional. A valid `https://` link to a well-known donation host — for example Boosty, Patreon, PayPal or YooMoney. Phishing or arbitrary hosts are rejected.
Changelog (RU + EN)	What changed in this version.

[!TIP] Write the descriptions for a real user who has never seen your plugin. “For dummies” is exactly right: say what it does, when to use it, and what it needs.

Step 3 — Declare the capability manifest

The capability manifest is the heart of the security model. It is a short, structured declaration of every permission your plugin needs — which hosts it talks to, which files it touches, whether it runs external commands, which channels and credentials it uses.

Why declare it

Customers see the requested permissions before they install and consent to them, just like a mobile app’s permission prompt.
The instance uses the manifest to restrict the plugin to what it declared.
Reviewers check that your declared capabilities match what the code actually does. A plugin that reaches for a permission it did not declare is rejected.

Principle of least privilege

Declare only what your plugin genuinely uses, and nothing more. Fewer permissions means faster review, easier customer consent, and more installs. If you do not touch the filesystem, declare an empty list. If you never spawn a process, set exec to false.

The format

The capability manifest is a JSON object with these fields:

Field	Type	Meaning
`network`	string[]	Hostnames the plugin connects to (its egress allowlist).
`filesystem`	string[]	Paths it reads or writes, relative to its own plugin directory.
`exec`	boolean	Whether it spawns external processes / runs commands.
`channels`	string[]	Messaging channels it integrates with (e.g. `telegram`).
`credentials`	string[]	Named secrets/config keys it uses (never the secret values).
`description`	string	A short, human-readable summary of what it needs and why.

Example:

{
  "network": ["api.example.com", "cdn.example.com"],
  "filesystem": ["./cache"],
  "exec": false,
  "channels": ["telegram"],
  "credentials": ["api_token"],
  "description": "Calls the Example API to sync tasks and posts replies to Telegram. Caches responses under its own ./cache directory. No process spawning, no other hosts."
}

[!WARNING] Do not put real secrets, tokens or keys anywhere — not in the manifest, not in the metadata, not in the artifact. Declare credentials by name only (e.g. api_token); the customer supplies the actual value at install time. Hardcoded secrets are an automatic rejection.

Step 4 — Upload the artifact

Upload your plugin build:

Format: a .tar.gz release tarball produced by aihummer plugin package.
It must contain the plugin’s manifest.json (the SDK manifest — kind, version, entrypoint, declared capabilities, config fields).
The capability manifest you filled in Step 3 must be consistent with what the code and manifest.json actually do.

You also attach the icon and screenshots here if you did not already.

[!TIP] Run aihummer plugin validate locally before uploading. The validation contract is the same one the marketplace uses, so a manifest that passes locally will be accepted here too.

Step 5 — Send for review

When every field is filled and the artifact is uploaded, click «Submit for review». The cabinet runs a completeness check first; if something is missing it tells you exactly what. Once accepted, the status moves to Submitted and then AI review — you do not need to do anything else.

Step 6 — Track the status and read a verdict

Open the plugin in «My plugins» to follow its status. When review finishes you will see one of:

In moderation — the automated review passed or only flagged minor things; a human is now looking at it. Just wait.
Rejected — something failed. You will see a verdict, a summary, and the specific items that did not pass (with the reason for each). This is your fix-list.
Published — approved, signed and live. Your plugin now appears on the AiHummer marketplace and installs into any instance that has the community catalog enabled.

How to read a rejection and resubmit

Open the plugin; read the failed items and their reasons.
Fix them — most are one of: a missing/weak description, a mismatched capability manifest, a hardcoded secret, a bad donation link, or a version you did not increment.
Edit the metadata and/or upload a new artifact with an incremented version.
Click «Submit for review» again. It goes back through the same pipeline.

[!NOTE] A rejection is not a penalty — it is a checklist. The review policy is public precisely so you can meet every requirement before you submit.

Where next

Review policy & checklist — the exact criteria your plugin is checked against.
Plugin SDK — build the plugin and its manifest.json.
Publishing a plugin — private side-load and the other publishing modes.
Install & updates — how customers install and how the trust model works.