Nuvaka › Developer docs › Review & publishing rules

Review and publishing rules

Every upload first goes through automatic checks. A version that passes is either published right away or waits for an administrator's review. This page explains which version goes where and what can happen afterwards.

Automatic rejection

If any of the following applies, the upload is rejected, the version is not stored at all and the errors are listed in the response (scan.errors). You can run the same checks without publishing with nuvaka-ext lint (local) or nuvaka-ext lint --remote (server).

  • Package limits: ≤ 20 MB compressed, ≤ 60 MB unpacked, ≤ 2000 files; files outside the allowed types, executables, symbolic links, .. or absolute paths.
  • Manifest: fields that break the schema, unknown or missing fields; entry/icon not in the package; another user's ID prefix; a version not greater than the latest uploaded one.
  • Forbidden code patterns: eval(, new Function(, timers with strings, remote import( and <script src>, importScripts, document.cookie, window.parent/top/opener, obfuscated (_0x…) code.
  • Permission/usage mismatch: a nuvaka.* namespace used in code without the matching permission in the manifest.
  • Publisher signature: an unsigned or wrongly signed upload while your account has a signing key registered.
  • Account: frozen or banned accounts cannot publish (403).
  • Email verification: uploading, store listing (listing, media), abandoning and adopting require a verified email, otherwise 403 email_not_verified. nuvaka-ext lint --remote (validate) works without it. Verify your email in the app with Send verification code under Profile › Developer.
  • Dependencies: a dependency not in the Store or blocked, no published version satisfying the range, a cycle, depth > 5, more than 10 packages in the install (including the root), a self-dependency or a duplicate ID; errors are prefixed with "Bağımlılık: …" (Dependencies).
  • Abandoned package: no new version can be uploaded to an abandoned package; once an adoption is approved, the new owner can upload.

The full list of rules and messages: Security rules. Warnings (e.g. a permission declared but never used, a large minified file without a source map) don't stop the upload; if the version goes to review, the administrator sees them together with the scan findings.

What goes to manual review

A version that passes the automatic checks waits in review for an administrator in these cases; until it is approved, users cannot see or install it:

CaseWhy
The publisher's first extensionUploads from a publisher with no published (or yanked) version yet are reviewed. Once your first version is approved, later uploads don't wait for this reason.
A version asking for a critical permissionEvery new version asking for nuvaka.mail (read/send), nuvaka.cloud: write or nuvaka.connections: secrets.
A new version of a "Nuvaka verified" extensionEvery version of a verified extension is reviewed; until it is approved, users stay on the previous approved version.
Extensions that add to Nuvaka screensEvery version of an extension that adds items to the Nuvaka UI through contributes in the manifest is reviewed, even for verified publishers and non-first versions (Core contributions).

All other versions go straight to published with the community trust level. The message in the upload response tells you why a version was sent to review.

After review

  • Approved: the version is published (the server signs its release record) and appears in the Store; it reaches users with automatic updates according to the update rules.
  • Rejected: the administrator must write a rejection note, which is shown to you (the version's reviewNote field in GET /api/ext/v1/dev/extensions). Fix the problem and upload again with a higher version number; a rejected version number cannot be reused.
  • Trust badge: published extensions start at community. An administrator can mark an extension "Nuvaka verified" (verified) or remove the badge. Verified extensions show the badge in the Store and appear under the "Nuvaka verified" filter; every later version of theirs goes to review.

Yanking and hiding

  • Yank: you can yank a broken version; it gets no new installs, and users on it go back to the previous one.
  • Unlist: you can hide your extension from the Store and show it again; installed users are not affected.

Blocking

  • An administrator can block a malicious or rule-breaking extension, or a single version of it; a reason is required and is shown to users.
  • The app applies the block list at start and whenever it changes: the blocked extension stops immediately on every device it is installed on. A blocked version cannot be downloaded (410) and cannot get an extension token.
  • Users can report an extension in the Store for malware, privacy, broken, spam or other reasons; reports are handled as support tickets. Store media also have their own media reports.

Removing a package

  • You can delete your extension with Remove under Profile › Developer › My apps: it leaves the Store and is stopped on every device it is installed on. This cannot be undone.
  • Packages others depend on cannot be deleted: if another published extension depends on this package with its latest version, the server returns 409 has_dependents with the list of dependents. In that case you can abandon the package instead.

Abandoned packages and ownership

  • Abandoning: Abandon package under Profile › Developer › My apps, or nuvaka-ext abandon <id>. The package stays in the Store at its last version; people who installed it and dependent extensions keep working; no new versions can be uploaded, and show/hide in the Store and yanking are disabled. A verified email is required. The publisher cannot undo abandoning.
  • Notifications: publishers of dependent extensions and users who installed the package are notified; dependent extensions show "a dependency has no maintainer" in the Apps screen.
  • Name: when abandoning you choose whether your name stays visible. If it does, the card says "No maintainer · formerly: name"; if you hide it, it says "former developer" and the package no longer shows up when searching by publisher name. The ID prefix (your username) does not change.
  • Adoption: another developer can send an adoption request from the abandoned package's store page with a reason (10–2000 characters); a verified email is required and there can be only one pending request per package per person. Requests are reviewed by a Nuvaka administrator. If approved, the package moves to the new developer with the same ID, the abandoned state is cleared and new versions come from them; installers keep receiving updates. Other pending requests for the same package are rejected. The requester is notified of the decision; a rejection note is shown. You can follow your requests under Profile › Developer › My adoption requests.
  • The former owner can no longer upload versions to an adopted package. The Store shows "Adopted · previous owner: name".
  • Vulnerabilities: if a vulnerability is found in an abandoned package, an administrator can block it; extensions that depend on it show "a dependency was stopped" (blocked).

Feedback box

When talking to users in the feedback box, avoid spam, harassment, asking for personal data and pushing users to contact you off the platform. If a user reports your message, the team reviews it; in serious or repeated cases the publisher account can be suspended. Details: Feedback box › Abuse.

Nuvaka Apps API v1 · last updated 2026-09-27