Creator Guidelines

Publish Like a Storefront, Not a Placeholder

A Magmaro listing is expected to function as a complete product page — not a draft, not a placeholder and not a minimal stub. Your title, summary, description, cover, icon, metadata, compatibility data, declared dependencies, external links and version history should collectively give a buyer everything they need to evaluate the product and make a confident purchase decision without needing to ask the creator basic questions first.

Thin listings, vague descriptions and placeholder copy reduce buyer trust, increase moderation friction and create avoidable refund and dispute risk. If your listing is not ready to function as a real storefront, it is not ready to be published. Waiting until the product page is complete is always better than publishing early and updating it later — first impressions from buyers and moderation reviewers both matter.

Titles and Summaries

Your title should accurately reflect what the product is. Do not use keyword-stuffing tactics, unrelated search terms or inflated category language to improve catalog visibility. The title is the first signal a buyer uses to decide whether to click — it should be honest, specific and descriptive enough to differentiate your listing from similar ones.

The summary is the short text that appears on catalog cards and search results. It should convey what the product does, at what level of scope, and for whom. A summary that could describe any product in the category — such as "A great plugin for your server" — tells buyers nothing useful and reduces the credibility of the listing before they even open the product page.

Be Honest About What the Product Is

Do not oversell the scope of your resource. If it is a configuration pack, call it a configuration pack. If it is a template, say so. If it is a plugin with a narrow use case or a specific server architecture dependency, describe that clearly. Buyers who discover undisclosed limitations after purchase create disputes, chargebacks and negative reviews that damage your reputation and your catalog's commercial performance.

If your product is genuinely broad, powerful or deeply featured, let the description demonstrate that with specific examples — feature lists, use cases, screenshots and documentation links. Do not expect buyers to assume quality on your behalf. Show it.

If the product is in early development, beta or subject to significant future changes, disclose that upfront. A buyer who knows they are purchasing an early product and agrees to that context is a far better outcome than a buyer who feels misled about the maturity of what they received.

Compatibility Metadata Must Be Real

Supported software, supported game versions, supported languages, compatible server platforms, game modes and filter tags should reflect what you have actually tested or intentionally built support for. Buyers use this metadata to make purchase decisions — it is not decorative. Filter and search results are built from this data, and a buyer who filters for Paper 1.21 compatibility and finds your listing expects it to actually work on Paper 1.21.

Misleading compatibility is one of the fastest ways to erode trust in a listing and attract disputes. If support is partial, limited, conditional on a specific configuration or untested on specific edge cases, explain that nuance clearly in the description rather than hiding it behind a clean-looking compatibility badge. Partial support disclosed clearly is better than implied full support that breaks in practice.

If a product update changes the compatibility surface — for example, dropping support for an older server version — update the compatibility metadata to reflect the new reality and communicate the change clearly in the changelog. Do not leave outdated compatibility claims on the listing after an update changes the actual support state.

Description Quality and Documentation

The description is the main body of your product page. It is where buyers read in detail what the product does, how it works, what it requires, what it includes, how to get started and what limitations apply. A strong description reduces pre-purchase questions, reduces post-purchase confusion, increases conversion and reduces dispute risk all at the same time.

At minimum, a complete description should cover: what the product does and its primary use case; key features and their scope; dependencies, requirements and setup prerequisites; known limitations or compatibility caveats; any configuration steps required to make it functional; and how buyers can reach you for support or questions. Markdown formatting is supported — use headers, lists and code blocks to make the page readable rather than a single block of text.

If your product has external documentation, a wiki or a GitHub repository, link to it. External documentation that is accurate and well-maintained reduces the burden on you to answer repeat questions and makes the product feel more professionally supported.

Covers, Icons and Visual Presentation

Visual assets should represent the product honestly and professionally. Your cover and icon are the most prominent visual signals buyers encounter before clicking into your listing. They should make the listing feel credible and accurate — not imply features, polish, bundled content or a scope that the actual product does not deliver.

Using stock imagery, AI-generated art or borrowed visuals is permitted where you have the appropriate rights to use them. Do not use images that imply the product is something it is not, and do not use covers that feature other creators' branding, trademarks or distinctive visual identities without explicit authorization.

A well-presented listing for a solid product builds durable trust and long-term sales. A stylish presentation for a thin or broken product accelerates disappointment. Prioritize getting the product right first, then invest in how it is presented.

Tags and Categorization

Tags and categories are how buyers find your product through search and filtering. Use tags that accurately describe the product's actual functionality, the platforms it targets, the game modes it supports and the use cases it addresses. Do not use unrelated or speculative tags to increase catalog surface area — this harms search quality for other buyers looking for genuinely matching products and may trigger moderation review of your listing.

Correct categorization also affects where your product appears in curated sections of the platform. Miscategorized listings disrupt buyer expectations on those surfaces and reduce the trust value of the category for everyone publishing in it honestly.

Package Uploads Must Match the Listing

The uploaded package must be the product the listing claims to sell or distribute. Do not upload broken placeholders, test builds, unrelated files, repackaged third-party content, empty archives or misleading file bundles. The file a buyer downloads should match exactly what the listing describes — in function, in scope and in the feature set implied by the product page.

Before submitting a release, verify the package yourself. Confirm that it installs correctly, does not throw errors on startup, and behaves as described. Submitting a broken build for moderation wastes review time and delays buyers from accessing an update they may be waiting for. A release that passes review but fails in common buyer environments creates immediate support burden and negative reviews.

Version Naming

Version strings should follow a clear and consistent scheme that buyers can understand and reason about. Common formats include semantic versioning (1.2.0), date-based versions (2026-04-07) or sequential builds (build-42). Whatever scheme you choose, apply it consistently across all releases of the same product.

Do not reuse version strings for different package content. If you submit version 1.2.0, fix a bug and resubmit, that new build should be 1.2.1 — not another submission labeled 1.2.0. Version strings are part of the public record of a product's history and are referenced by buyers in support discussions and bug reports.

Changelog Quality

Version changelogs are public and persistent. Buyers read them to understand what changed, why they should update and whether an update affects their current setup. Future buyers read changelog history to evaluate whether a product is actively maintained and how the creator communicates with their audience.

A good changelog entry is specific. It should clearly identify what changed: bug fixes by symptom or error type, new features by name and behavior, compatibility changes by platform and version, and configuration additions or removals by key name. Vague entries like "minor improvements," "bug fixes" or "performance update" without any specifics are not useful changelogs — they are placeholders that signal low maintenance quality to buyers evaluating the listing.

If an update introduces breaking changes, requires buyer action to migrate or removes functionality that was previously available, that information belongs at the top of the changelog in bold or a dedicated notice — not at the end, not in a sub-item and not omitted entirely. Buyers who upgrade without warning and then encounter a broken server or lost configuration will blame the product before they read a footnote.

Protect Existing Buyers During Updates

Magmaro's review workflow ensures that pending listing changes and pending version updates do not automatically replace the currently approved live state visible to buyers. Use this system responsibly. Buyers who have already purchased and deployed your product depend on the live version being stable. An update that silently changes behavior, narrows the compatibility surface or introduces regressions affects real production deployments.

If a new version has breaking changes, a reduced compatibility surface, changed configuration structure or modified defaults, be explicit about that at the top of the changelog. Consider whether it is appropriate to maintain a legacy version download or provide a migration guide alongside the update. Creators who handle breaking changes carefully and communicate them clearly retain buyer trust even through significant product evolution.

Do not use the version system to replace the distributed package with materially different content without a corresponding version bump and changelog. Silent file replacement without a proper version record harms platform integrity and removes the audit trail buyers and Magmaro rely on.

Package File Safety

All uploaded packages must be safe for buyers to download and use. This is an absolute requirement with no exceptions. Do not upload packages that contain malware, spyware, unauthorized data collection, undisclosed network communication, hidden executables, exploit code or any content designed to harm, compromise or surveil the systems of buyers who install your product.

Do not upload packages that contain content violating third-party intellectual property rights, adult or harmful content, or assets you do not have the right to distribute. Magmaro may scan and review uploaded packages. Packages identified as harmful, rights-infringing or policy-violating will be removed and the associated account will face enforcement action as described in the Terms of Service.

Pricing Credibility

Set your prices at a level that honestly reflects the value and scope of your product. Buyers on Magmaro evaluate price alongside description quality, compatibility claims, version history and reviews — not in isolation. A price that is dramatically inconsistent with what the product actually offers in either direction creates friction: too high relative to scope generates disputes and refund requests; too low can undermine perceived quality before buyers even read the description.

You are not required to set any specific price, and Magmaro does not dictate commercial terms. But as a creator, setting and maintaining credible, stable pricing is part of your commercial reputation. Frequent unexplained price swings, deeply inconsistent pricing across similar products or pricing that appears manipulative may attract additional moderation scrutiny.

Offers and Time-Limited Discounts

Magmaro supports time-limited offers as a legitimate commercial tool for launch promotions, seasonal campaigns, community events or price experiments. An offer should represent a genuine discount from a real established price. Artificially inflating the standard price and then running a perpetual offer to simulate a discount undermines the credibility of your pricing and of the offer system as a whole.

Offers are subject to platform cooldown rules — a new offer cannot be created immediately after a previous one ended on the same resource. This is by design to prevent permanent discounting presented as a series of temporary offers. Respect the intent of these rules rather than attempting to work around them. Maximum duration limits are also enforced.

A buyer who purchases during an active offer pays the discounted price and receives the same product and access rights as a full-price buyer. Do not apply different support quality, feature access, update frequency or communication standards to buyers based on whether they paid a discounted price. A sale at any price is a full sale.

Coupons and Creator Campaigns

Coupon codes are a targeted discount mechanism — they require the buyer to know and actively use the code. They are appropriate for community giveaways, newsletter promotions, partner referral arrangements, event-specific campaigns or private discounts for specific buyer groups. Use them for cases where the intent is to reach a specific audience with a specific offer rather than discounting your listing broadly.

Do not distribute coupon codes in ways that undermine standard pricing for all buyers — for example, posting active coupon codes publicly in ways that make them available to anyone indefinitely has the same commercial effect as simply lowering the price, but with the added confusion of inconsistent checkout prices for different buyers. If the offer is genuinely for everyone, use an offer instead.

Advertising and Promotional Slots

Buying a featured slot or catalog placement amplifies the visibility of your listing. It does not lower the quality standard the platform or buyers apply to it. A promoted listing will be seen by more buyers — buyers who arrive with expectations calibrated to a featured product. Promotion on top of a weak listing generates clicks that end in abandonment, refund requests and negative reviews. Promotion on top of a strong listing generates purchases, positive reviews and return buyers.

Before booking ad placement, ensure your listing meets the full standards described in these guidelines: complete description, accurate compatibility metadata, honest scope claims, working package, proper version history and a professional visual presentation. Investing in promotion before the listing is ready wastes the advertising budget and creates a worse outcome than simply waiting until the listing is properly finished.

Ad bookings are calendar-based and first-come, first-served per slot. Dates already booked by another creator are not available. Booked past dates cannot be cancelled or refunded. Plan promotional campaigns in advance and book the specific dates that align with your intended promotion timing rather than booking far-future dates speculatively.

Revenue, Fees and Commercial Obligations

Creators are responsible for understanding the platform's fee and commission structure before publishing paid listings. Magmaro applies applicable fees and commissions at the time of payout through Stripe Connect. The current rates are described in the platform documentation and may be updated over time with reasonable notice.

As a creator earning commercial revenue through Magmaro, you are responsible for meeting any tax reporting obligations, VAT or sales tax compliance and other legal obligations that apply to your commercial activity under the laws that govern you. Magmaro does not act as your tax agent or legal representative. If you are unsure about your obligations, consult a professional in your jurisdiction before publishing paid listings.

Source Availability, DRM and Obfuscation

Disclose clearly and prominently whether the product is open source, source-available under a specific license, or distributed exclusively as compiled binaries without source access. Many buyers treat this as a purchase-critical piece of information — particularly developers who need to audit code running on their infrastructure, or server owners who need to verify the product does not contain unexpected behavior.

If the distributed package includes code obfuscation, disclose that. If the product includes any form of DRM, license validation, remote authentication, server-side gating, activation requirements, usage metering or any mechanism that can affect the product's functionality based on account state, subscription status, hardware ID or network connectivity — disclose all of it upfront, prominently, on the product page. These are not minor implementation footnotes. Discovering them post-purchase without prior disclosure is one of the most common causes of disputes, refund requests and negative reviews on the platform.

If your licensing system can result in the product becoming non-functional — for example, if your license server goes offline, if your subscription service shuts down, or if a buyer's license is revoked — buyers are entitled to know that before they purchase. Disclose both the existence of the licensing mechanism and the consequences of edge cases honestly.

Network Communication and Data Collection

If your product communicates with any external server, service or API — including servers you operate yourself — disclose that communication in the product description. Specify what data is transmitted, why it is transmitted and to where. Buyers have a right to know whether software they install on their infrastructure is making outbound connections, regardless of the stated purpose.

If your product collects any telemetry, usage data, error reports, user identifiers or other information — even for legitimate purposes such as update checks, analytics or support — disclose what is collected, where it is sent and how long it is retained. Do not collect or transmit any data that the buyer has not been informed about in advance. Undisclosed data collection in a distributed product is a serious violation of these guidelines and the Terms of Service.

Rights and Originality

Only upload and sell content you have the legal right to distribute. This applies to all elements of your product: source code, compiled binaries, configuration files, asset packs, models, textures, audio, artwork, icons, cover images, documentation and any bundled third-party components. You must either own the rights to all elements of your listing or hold appropriate licenses or explicit permissions that permit commercial redistribution in your specific use case.

If your product builds on, forks, extends or incorporates someone else's work, credit them appropriately where required by the applicable license and verify that the license actually permits commercial redistribution, modification and distribution in the form you are offering. Open source licenses vary significantly in their commercial redistribution terms — "it has a public repository" does not automatically mean you can sell it commercially. If you are unsure, check the license terms explicitly before listing.

Do not repackage or resell other creators' Magmaro products, other marketplace products or any distributed software as if it were your own work. Do not take free community resources and list them as premium products without adding meaningful original value and ensuring all applicable licenses permit it. Rights misuse is enforced and may result in immediate listing removal and account restrictions.

Dependencies and Third-Party Requirements

If your product requires any external software, library, service, account, API, database, server framework, operating system or hardware configuration that the buyer must obtain, install or configure separately, list every one of those requirements explicitly and prominently on the product page — ideally in a dedicated section at the top or in a structured requirements list, not buried in the middle of a long description.

Common dependencies that must be disclosed include: specific server software versions or forks (e.g. Paper 1.20+, Velocity 3.x); plugins or frameworks that must be installed first; paid third-party licenses the buyer must separately acquire; specific Java versions; access to an internet-connected service you operate; database instances or external configuration tools; and any cloud account or API key the buyer must create to activate features.

A buyer should never complete a purchase, download the package, attempt setup and only then discover a requirement that prevents the product from functioning. That experience is a failure of listing quality regardless of how good the product itself is. Complete dependency disclosure is not optional for paid listings.

Scope and Limitations

Every product has limitations. A listing that implies unlimited scope, no configuration required, works on everything or plug-and-play simplicity will produce disappointed buyers when the reality differs. It is better to accurately state what the product does not support than to imply it does and then deal with the support and dispute consequences.

Known limitations worth disclosing explicitly include: platforms or server software that are not supported; game versions that have not been tested; features that require additional configuration to activate; functionality that depends on specific world setups; performance considerations on large servers; and any aspect of the product that a reasonable buyer might assume is included but is not.

Support Expectations

Buyers of paid resources reasonably expect some level of creator engagement after purchase. This does not mean unlimited custom development, on-demand 24-hour response times or free scope extensions beyond what the product was sold as. It means that if a buyer has a genuine product question, a setup issue or encounters a bug that appears to be in your code, you are expected to engage with it in good faith.

You do not have to guarantee any specific response time, and you are not obligated to implement feature requests. But you should not disappear after a sale, ignore critical bug reports indefinitely or leave messages about product-breaking issues unanswered for extended periods. Buyers who paid for a working product and encounter a clear defect are entitled to at minimum an acknowledgment of the issue and a timeline for addressing it.

Your support behavior is visible. Messages, resource discussion threads and profile activity all contribute to your public reputation on the platform. A consistent pattern of ignored support requests, unacknowledged critical bugs and absent creators after sale is noticed by future buyers evaluating whether to purchase, and it is noticed by platform moderation when disputes arise.

Handling Reviews Professionally

You will receive critical reviews. Some will be fair and based on real product issues. Some will reflect misunderstandings or misconfiguration. A few may feel unfair or be based on incomplete information. How you respond to all of them — publicly — defines a significant part of your creator reputation on the platform.

Do not attempt to pressure buyers into modifying or removing honest feedback. Do not use private messages to retaliate against users who left a public review you disagree with. Do not offer refunds or incentives contingent on review modification — this is review manipulation and is prohibited under the Terms of Service regardless of the commercial arrangement involved.

When responding to a critical review publicly, keep your reply factual, constructive and focused on the product. Acknowledge valid points honestly. Correct factual inaccuracies calmly with evidence. Avoid defensiveness, personal attacks or the kind of response that makes potential buyers wonder whether you would react the same way to their own support requests. A good public response to a critical review routinely creates more buyer trust than a perfect average rating.

Communication Conduct

All of the conduct standards in the Terms of Service apply to creators with equal weight. Creator status does not grant elevated permissions to behave in ways that would be moderated for any other user. This includes communication through private messages, resource discussion threads, profile posts, review replies and any other platform surface.

Do not use messaging or profile tools to spam other users with unsolicited promotion of your listings. Do not use discussion threads on other creators' products to cross-promote your own. Do not make disparaging public comments about competing listings or other creators. Do not use your platform presence to organize pressure campaigns, coordinate review manipulation or engage in the kind of commercial aggression that degrades the community for everyone.

Creators are often the most visible participants on the platform. How you interact with buyers, other creators and the broader community is a more lasting signal of your reliability as a vendor than any single listing or feature set. Platform reputation is slow to build and fast to damage.

Account Integrity

Do not operate multiple accounts to circumvent enforcement, manipulate review scores, generate fake purchases, create artificial license counts, inflate download statistics or gain unfair advantage in any platform system. Multi-account activity for these purposes is a violation of the Terms of Service and will result in enforcement across all associated accounts.

Do not share your API key with third parties, distribute it in publicly accessible code repositories or use it in client-side code. Your API key has full creator-level access to your account. Treat it with the same care you would treat a password. If your key is exposed, revoke it immediately from account settings and generate a replacement.

Community Behavior

Creator profile posts, resource discussions and private messaging are designed for genuine and useful communication between creators and the platform community. They are not a venue for commercial spam, aggressive self-promotion outside contextually appropriate spaces, public targeting of other creators or users, harassment, coordinated pressure tactics or any other behavior that degrades the quality of shared spaces on the platform.

Magmaro is a focused community. The number of active creators and buyers is not enormous, which means individual behavior has a proportionally larger effect on the environment than it would on a massive generic platform. How you consistently conduct yourself in public interactions becomes part of your permanent brand on Magmaro. Behave in ways you would be comfortable with any potential buyer reading.

Common Mistakes to Avoid

• Vague summaries — A summary that could describe any product in the category tells buyers nothing. Be specific about what the product is and who it is for.
• Misleading tags and categories — Tags used for catalog visibility rather than accurate classification harm search quality for everyone and may trigger moderation review of your listing.
• Fake or premature roadmaps — Promising features that are not in active development inflates perceived value and sets buyers up for disappointment when those features do not arrive.
• Padded or empty changelogs — "Minor improvements" is not a changelog. Consistently vague update descriptions signal to buyers that the product is not maintained with care or transparency.
• Undisclosed dependencies — Any requirement the buyer must separately obtain, install or configure belongs on the product page before purchase, not discovered post-installation.
• Inflated compatibility claims — Listing software versions you have not tested reduces confidence and generates support requests from buyers who find it does not work as claimed.
• Perpetual discount patterns — Running overlapping or consecutive offers or coupons indefinitely removes pricing credibility and undermines the perceived value of your actual price.
• Premium presentation without substance — High-quality cover art cannot compensate for an incomplete description, missing dependency disclosure or a package that does not work as advertised.
• Silent file replacement — Replacing the distributed package file without a proper version bump and changelog removes the audit trail buyers and the platform rely on.
• Undisclosed network communication — Any outbound connection your product makes — even for benign purposes — must be disclosed before purchase.
• Disappearing after a sale — Ignoring messages and bug reports after a paid listing generates a purchase damages your long-term reputation faster than any negative review.
• Retaliating against reviews — Using private messages or public replies to pressure, threaten or discredit buyers who left honest feedback is prohibited and escalates moderation risk significantly.

What Good Listings Actually Look Like

Listings that build durable commercial success on Magmaro consistently share a small set of characteristics. They are honest about scope — not modest to a fault, but not inflated either. They declare every dependency the buyer will encounter. They explain what the product requires, what it does not support, and what a buyer can realistically expect after installation. Their compatibility metadata is accurate because someone checked.

Their changelogs tell a readable story of a product being maintained and improved over time. Their support responses in discussion threads and private messages are present, professional and focused on solving the buyer's actual problem. Their promotional activity — offers, ads, coupons — is used judiciously rather than continuously. And their visual presentation is honest rather than aspirational.

These things are not complicated individually. The challenge is doing all of them consistently, across every listing, for the full lifetime of each product. That consistency is what separates creators who build sustainable businesses on the platform from those who generate short-term sales followed by a trail of disputes, abandoned listings and a declining review average.

The Real Standard

The baseline question for every listing is straightforward: if a buyer arrives at this product page with no prior context, no existing relationship with the creator and no supplementary information from outside the platform, can they understand what the product is, what it requires, what it supports, what they receive after purchase and who is responsible for it? If the answer is no, the listing still needs work — regardless of how good the underlying product actually is.

A great product behind a confusing, incomplete or misleading listing page is still a poor buyer experience. The listing is part of the product. The support behavior is part of the product. The changelog communication is part of the product. Buyers evaluate the complete experience, not just the JAR or ZIP they download.

Magmaro is a marketplace where creator reputation is public, persistent and built incrementally over every interaction. Everything else — advertising, promotional campaigns, coupon codes, featured slots, profile activity — works better and delivers better returns on top of a foundation of listing quality, commercial honesty and genuine support engagement. That foundation is what these guidelines exist to describe.