Skip to main content

SCNX Marketplace Publishing Guidelines

Important note

These policy are subject to review and changes as the product they govern isn't available to non-approved partners yet.

About this document

These guidelines explain how publishing on the SCNX Marketplace works in practice: what our review looks for, what gets content approved or rejected, and how to keep your content in good standing.

They are a practical companion to the Shared Marketplace Content Terms of Service ("Marketplace Terms") and the SCNX Terms of Service. They do not replace either document if anything here appears to conflict with the Marketplace Terms, the Marketplace Terms prevail. Nothing in these guidelines limits the rights SCNX reserves there.

Last Updated: July 14, 2026

1. Before you publish​

Every listing on the Marketplace is something another community will trust to run on their server. Before you submit:

  • Test in a live server. Import and run your content on a real test server first. Slash commands should register, flows should complete without errors, and configuration pages should work with fresh values. The Marketplace Terms make pre-publication testing and quality control a hard requirement (§2.3).
  • Parameterize everything server-specific. Content must work on any server. Never hardcode role IDs, channel IDs, or user IDs (Marketplace Terms §3.3). For modules, put server-specific choices (channels, roles, thresholds) on a configuration page so importers set them during setup. The dashboard's validation and transparency checks flag hardcoded identifiers; fix them before submitting.
  • Never include secrets. API tokens, webhook URLs with embedded credentials, passwords, or any other secret must not appear anywhere in shared content (not in flow steps, not in default configuration values, not in descriptions, ...). Shared content is distributed, inspectable, and re-shareable; treat every value in it as public.
  • Disclose every external call. If your content makes HTTP requests, every external host it contacts must be named and explained in your listing (Marketplace Terms §3.4). Importers see external hosts in the import consent screen; an undisclosed endpoint discovered later is grounds for removal and action against the Publisher.
  • Remember the data-transmission rule. Marketplace-distributed commands must never transmit data obtained from Discord (messages, user details, server information) to external APIs or third-party servers; in any scenario (Marketplace Terms §3.4). External calls are for fetching into Discord, not exporting out of it.

2. Listing quality standards​

Your listing is your storefront. We hold listings to the standard of other professional digital-asset marketplaces (Marketplace Terms §2.10):

  • Accurate title and description: describe what the content actually does. No exaggerated claims, no bait-and-switch, no keyword stuffing.
  • Complete metadata: category, tags, and a language declaration that match the content. Mis-categorized or mis-tagged content may be unlisted until corrected.
  • Screenshots and media: must show the actual content, be hosted on official SCNX media hosting (uploads through the dashboard land there automatically; hotlinking external images is prohibited, Marketplace Terms §3.5), and be images you own the rights to. Note that once published, marketplace media cannot be deleted, as it may be in use by importers.
  • Setup guide: if your content needs any manual step after import (filling configuration values, adjusting role hierarchy, creating a channel), your listing must walk the importer through it.
  • Support links: keep the support contact on your organization profile and listings current. Persistently ignoring legitimate support requests can lead to demotion or removal (Marketplace Terms §2.6).
  • Changelogs: every update you publish must carry an accurate changelog describing what changed (Marketplace Terms §2.9). Importers see your changelog before applying an update to a live server; write it for them.
  • Documentation parity: if you document your content in more depth on an external site, your SCNX listing must be at least as complete (Marketplace Terms §3.7).

3. How review works​

Different checks apply at different stages:

  1. Automated scanning runs on every submission and update, for every content type. It checks for policy violations, malicious or dangerous logic patterns, embedded personal information, hardcoded server-specific identifiers, undisclosed external endpoints, and schema/compatibility problems. Flagged content can be hidden or rejected automatically (Marketplace Terms §7.1).
  2. Automated pre-checks in the publish flow surface most problems before you submit, including the transparency summary of what your content does and which external hosts it contacts. Resolve everything the publish panel flags; it is checking the same things review checks. Each published version of a module also passes an automated version review, a version must be approved before the module can apply for curation.
  3. Curation exists for custom command modules and determines whether a module appears in the public marketplace at all:
    • Without curation, your module is unlisted. It is fully importable and shareable via its key or unlisted link, but it does not appear in public browsing, search, or your organization's public module count.
    • To be publicly listed, apply for curation from your listing's dashboard. The application is a short questionnaire; submitting it requires at least one approved, non-revoked version of your module.
    • Outcomes:
      • Listed: your module appears in public browsing and search.
      • Featured: additionally promoted (front page, collections). Featuring is editorial; being listed does not entitle a module to featuring.
      • Changes requested: the review found specific fixable issues. The reviewer's note appears on your listing's dashboard; fix the issues and resubmit together with a short "what we changed" summary. Having changes requested from our team is completely normal and part of the process - we're working with you to improve your module!
      • Revoked: a previously listed module was removed from public browsing because it no longer complies. The reason is shown on your listing, and an appeal path is available (Section 9).
  4. Periodic automatic and manual reviews of modules: SCNX may automatically or manually verify modules for compliance for Guidelines. You will be notified about issues we've found the same way as described above.

Messages and configuration templates are distributed via import keys and are not part of the public curation program, but automated scanning and all content rules in Section 4 apply to them in full.

Listing and surfacing are always at SCNX's discretion (Marketplace Terms §5.1). These guidelines make our criteria predictable, but they are not a guarantee of placement.

4. What gets content rejected or removed​

The full rules live in the Marketplace Terms §3; in practice, these are the violations we act on most:

Immediate removal, no fix window (Marketplace Terms §7.2, §7.4):

  • Personal information in content, or content designed to collect personal information from server members under false pretenses (§3.2)
  • Data scraped or bulk-fetched from the Discord API (§3.1)
  • Malicious logic: crash attempts, infinite recursion, rate-limit evasion, or logic that transmits Discord-obtained data to external servers (§3.4)
  • Illegal content, sexually explicit content, or clear intellectual-property infringement (§3.6)
  • Spam tooling: mass-messaging, unsolicited bulk DMs, raid automation (§3.4)

Notice with a fix window (typically 7–14 days) for everything else (like inaccurate listings, missing disclosures, broken content, metadata problems, documentation-parity gaps). You will be notified through the dashboard and by email with what needs to change. If the deadline passes without a fix, the content is unlisted or removed.

Retroactive removal: for severe violations, SCNX can remove or disable already-imported copies of your content directly from end-users' bots (Marketplace Terms §7.3). This is reserved for content that poses a security or compliance risk to the servers running it.

Account-level consequences: severe or repeated violations can end in termination of your organization's marketplace access or your personal SCNX account, and (for commercial publishers) contractual penalties (Marketplace Terms §7.5–§7.8).

5. Data protection for publishers​

If your content processes personal data of server members (for example, a custom command that stores per-user records), you are an independent data controller for that processing (Marketplace Terms §8.2). Concretely:

  • Say in your listing what member data the content stores and why. Your storage schema is part of your product; importers and their members deserve to know what it holds.
  • Design for data minimization: store what the feature needs, nothing more. Content whose storage design collects data beyond its stated purpose will not pass curation.
  • Content must never solicit sensitive real-world data (identity documents, health data, addresses, payment details) from server members, regardless of consent screens or disclaimers (Marketplace Terms §3.2).
  • If your content automates moderation decisions (automatic timeouts, bans, role removal), tell importers in your setup guide that they owe their members transparency about automated decisionsm see the Custom Commands Usage Guidelines they will be operating under.

6. AI-assisted content​

Content authored or partially authored with AI tooling (including SCNX's own AI-assisted flow generation) is welcome on the Marketplace under the same standards as everything else. You are the publisher: you are responsible for testing it, understanding what it does, and warranting the rights to it, exactly as if you had written every step by hand. "The AI generated it" is not a defense in review or enforcement.

7. Monetization​

You may monetize your content off-platform (external storefronts, commissions) as long as the content itself complies with these guidelines and the Marketplace Terms. Present it honestly: a paid listing is held to the same accuracy and support standards as a free one, and monetizing makes you a commercial actor with your own legal obligations (Marketplace Terms §5.4). If SCNX introduces native monetization, price-parity requirements apply (Marketplace Terms §5.5).

8. Staying published​

  • Maintain your content. When SCNX or Discord platform changes break it, update it or clearly mark it as legacy. Perpetually broken content is unlisted to protect importers (Marketplace Terms §2.8).
  • Stay active. Content from accounts inactive for twelve months may be archived or unlisted (Marketplace Terms §7.7).
  • Engage with reviews professionally. You can reply to reviews on your listing; you cannot demand removal of legitimate negative reviews (Marketplace Terms §5.3).

9. Reporting and appeals​

  • Reporting: if you find marketplace content that violates these guidelines or infringes your rights, report it with the content's key/URL and evidence to [email protected] (Marketplace Terms §9.1).
  • Appeals: if you believe a review or enforcement decision on your content was wrong, use the appeal link shown on the decision itself in your dashboard (for example on a revoked listing's status card), it opens a support ticket pre-filled with the right context, which is the fastest way to a manual review. Decisions communicated with a fix window are usually fastest to resolve by simply making the requested change and resubmitting. For formal legal matters, [email protected] remains the designated contact (Marketplace Terms §9.2–§9.3).