Submission Guidelines
We welcome original, thoughtfully built add-ons and starter kits. Products must meet the applicable requirements below before they can be listed.
We're excited to see what you're building with Statamic! We keep the marketplace curated and focused so people can find original, well-built products they can count on. These guidelines explain what we're looking for in a listing here. You're always welcome to share or sell your work elsewhere if the marketplace isn't the right fit.
AI tools are welcome. You remain responsible for reviewing the code, making deliberate design decisions, testing the finished product, and maintaining what you ship. We evaluate the work, not the tools used to create it.
These requirements apply to free and paid products. A small, focused product can meet them just as well as an ambitious one.
Already in the marketplace? These guidelines apply to existing products too. Listings that don't meet them may be unpublished. You may need to rework your product and submit it for another review before it can be approved and published again.
All products
01 Offer substantial original value
Your product must contribute a distinct design, capability, or workflow. Cosmetic variants belong within one product.
Acceptable
Two podcast kits with substantially different designs and publishing experiences. Bringing your own original design from another platform to Statamic with a thoughtfully built native implementation. An integration that makes a specific service work naturally in Statamic. Multiple color schemes bundled with one kit.
Not acceptable
Selling the same kit repeatedly with different names, colors, images, or industry labels. Lightly reskinning a purchased template or another creator’s kit.
Shared libraries, frameworks, and foundations are fine. Neither overlapping audiences nor familiar design patterns alone demonstrate duplication. Converting someone else’s finished template to Statamic does not, by itself, establish substantial original value.
Starter kits & add-on integrations
02 Use Statamic’s native capabilities appropriately
Starter kits must model content in Statamic. Add-ons must integrate through supported extension points.
Acceptable
Navigation managed through Navigations or an appropriate collection-driven menu; shared settings in Globals; content images in asset fields; entries in Collections; collection mounting where the site structure calls for it.
Not acceptable
Hard-coded editable menus, footer details, or article lists. URLs that break when an entry moves. Modifying Statamic core files to make an add-on work.
Decorative assets and fixed utility links may remain in templates. Products do not need to use features unrelated to their purpose.
Starter kits & content-editing add-ons
03 Make content editable and components reusable
Routine editing must work without editing code, including HTML stored in a textarea. Shared structures should have a maintainable implementation.
Acceptable
Clearly labeled blueprints; appropriate field types; reusable fields and partials; editors can add, remove, and reorder the content the product promises to support.
Not acceptable
An entire site stored in one HTML field; a menu that requires editing HTML in Globals; duplicated headers that must be edited separately; adding a testimonial requires changing a template; empty optional fields leave broken markup.
A kit does not need a universal page builder. A focused editing model is welcome. Moving markup into an editable field does not make it structured content.
Products with a visible interface
04 Deliver deliberate, consistent design
Visible interfaces must demonstrate coherent typography, hierarchy, spacing, imagery, and interaction design.
Acceptable
A restrained blog kit with excellent typography and consistent layouts. An expressive design whose visual choices remain coherent across pages and states.
Not acceptable
A polished homepage paired with unfinished inner pages; clashing component styles; illegible text over images; arbitrary spacing; controls that look interactive but are not.
Minimal and unconventional designs are welcome, and a low price does not count against your product. Make deliberate visual choices and carry them consistently through the whole experience.
Products with a visible interface
05 Work beyond the demo’s happy path
Interfaces must work with realistic content, small screens, and keyboard navigation.
Acceptable
Menus usable by keyboard; labeled forms; visible focus; readable contrast; long titles wrapping correctly; useful empty and error states.
Not acceptable
A mobile menu that cannot close; hover-only controls; clipped headings; unreadable contrast; missing images breaking layouts; a form showing success without processing anything.
Test the features actually included. Features needing customer credentials may require setup, but must explain that requirement and handle missing configuration.
All products
06 Ship an installable, compatible release
Review the release customers receive, using the installation instructions and compatibility claims supplied with it.
Acceptable
A tagged release installs into a fresh site with the required blueprints, configuration, dependencies, and production assets. Any required build steps are documented and reproducible.
Not acceptable
A demo works only in the author’s checkout; missing globals or assets; references to local paths; undeclared dependencies; advertised version support that fails installation.
Add-on updates must preserve existing customer content and configuration. Supporting only older Statamic versions is acceptable when those versions are clearly identified and the product works as documented. Beta and experimental releases must be clearly labeled, disclose limitations and breaking changes, and provide reproducible installation instructions, including any development-version constraints. Age or beta status alone is not a rejection reason; neither excuses broken installation, unsafe behavior, or failure to meet other applicable requirements.
All products
07 Protect customer sites and data
Use appropriate authorization, validation, escaping, and secure handling of credentials and external services.
Acceptable
Server-side permission checks; credentials supplied through configuration; documented external requests; failures handled without exposing secrets or destroying data.
Not acceptable
Committed API keys; unauthorized access to control-panel actions; hidden tracking; silently sending customer content elsewhere; destructive migrations without an explicit, documented migration process.
A clean automated scan does not establish compliance, and marketplace approval is not a comprehensive security audit.
All products
08 Have permission to distribute everything included
Bundled code, fonts, imagery, icons, and demo content must have documented redistribution rights and required attribution.
Acceptable
Original assets or properly licensed third-party materials, with applicable notices included. Demo-only assets clearly identified as excluded from the download.
Not acceptable
Redistributing assets without permission; assuming a license to use a template also permits reselling its source; removing required attribution.
Redistribution permission does not make a cosmetic reskin eligible under Rule 01.
All products
09 Document the product and provide a support path
Customers must be able to install, configure, use, and maintain the product without guessing.
Acceptable
Accurate installation instructions, a working example, configuration guidance, dependency disclosures, a changelog, and a functioning support channel. Community support is acceptable when clearly stated.
Not acceptable
Generic boilerplate documentation; instructions for another product; undocumented paid dependencies; dead support links; advertised support that is not provided.
All products
10 Represent the shipped product honestly
The listing, screenshots, demo, pricing, and compatibility claims must match the submitted release.
Acceptable
Screenshots from the actual product; clearly stated inclusions and limitations; disclosed paid services; a working starter-kit demo. Add-ons show relevant screenshots or a concrete usage example.
Not acceptable
Mockups presented as functioning features; demo capabilities absent from the download; hidden subscription requirements; inaccurate compatibility claims; keyword-stuffed or misleading descriptions.
Starter kits require a working live demo. Add-ons without a visual interface do not need an artificial demo site.
Add-ons
11 Respect Statamic’s Core and Pro boundaries
Add-ons whose purpose is to bypass or circumvent Statamic’s Core and Pro feature or licensing restrictions are not eligible for the marketplace.
Acceptable
Extending Core through supported APIs while respecting its edition limits. Requiring Pro for functionality that depends on Pro features. Integrating with an external service without evading Statamic’s restrictions.
Not acceptable
Unlocking additional users or forms in Core by disabling or working around edition checks. Giving multiple people separate passwords or identities behind a shared Core user to evade the user limit. Disguising multiple forms as one to evade the form limit. Disabling Pro license checks.
This rule concerns products designed to circumvent edition restrictions. An add-on is not in violation merely because it extends Core or has functionality that overlaps with Pro. Reviewers must identify the restriction being bypassed and the mechanism used; using a supported API does not make deliberate circumvention acceptable.
After a review
If your submission isn’t accepted, the feedback should cite the relevant rules, explain what we found, and make the next step clear.
- Changes required
- Specific shortcomings can be addressed in this product. Feedback identifies the rule, the observed problem, and what must change before resubmission.
- Not eligible in its current form
- The product requires substantial original work or a fundamental rebuild. A few cosmetic fixes won’t be enough for reconsideration.
What useful feedback looks like
Rule 02 — Native Statamic integration: The primary navigation and footer contact details are hard-coded. Move them into suitable Statamic content structures and verify that an editor can change them without editing templates. Resubmit after addressing this.
Rule 01 — Original value: This submission repeats your existing kit’s layouts and content model with different colors and photographs. These changes belong in the existing product. This submission needs substantial differentiation before reconsideration.
Required fixes should be distinguished from optional suggestions. Fixing reported issues triggers another review, not automatic approval. Suspected AI involvement is never a substitute for evidence.