folder Where to put your manifest(s)

OpenMods accepts two filename forms: openmods.json and openmods-anything.json. The suffix is just a human label — the mod's actual identity comes from the manifest's slug field. Pick whichever layout fits your repo:

• looks_one Single mod — one openmods.json at the repo root.
• looks_two Multi-mod, one folder per mod — one openmods.json inside each mod's folder.
• looks_3 Multi-mod, all in one folder — one openmods-label.json per mod, sharing the same folder (and a single media/ next to them).

OpenMods globs for both filename forms up to 4 directory levels deep and skips common noise paths (node_modules, .git, bin, obj, dist, build, target, vendor, examples, sample(s), test(s), __tests__, fixtures).

stacks Multiple mods in one repository

Drop an openmods.json inside each mod's folder, or sit several openmods-label.json files next to each other in a single folder. Either way, every manifest in a multi-mod repo must declare a slug (its stable identity within the repo) and a supportedGameId. Use releaseAssets patterns to decide which files from a shared GitHub release belong to each mod.

Example — one GitHub release ships zips for both games, each mod picks its own:

• check_circle The first published mod from a repo can stay as it is. The second time you commit a manifest, OpenMods auto-converts the repo to multi-mod and starts surfacing siblings.
• check_circle Newly-discovered manifests show up in your dashboard as drafts — click Publish to make them live.
• check_circle If you remove a manifest from the repo, the matching mod is auto-archived. Restore it by re-committing the manifest.
• warning Duplicate slugs across manifests in the same repo abort the whole sync — fix the duplicate and the next webhook re-applies cleanly.

data_object openmods.json — full example

Every top-level field is optional. Omit a section and that area of your mod page stays untouched.

fingerprint slug, name, supportedGameId — mod identity

Required for multi-mod repos. Optional for single-mod repos (omit them and the dashboard values you picked at publish time stay in charge).

filter_alt releaseAssets & primaryAsset — choose which files

Glob patterns that decide which files from a GitHub release sync into this mod. Useful in multi-mod repos where one release ships zips for several games; each manifest grabs its own.

description readme — custom README per mod

Point at a markdown file to use as this mod's page body. Useful for multi-mod repos where each mod deserves its own write-up instead of sharing the repo's root README.md.

link links — sidebar links

A list of external links rendered as a styled sidebar section.

image media & thumbnail — gallery

media is the gallery in display order. thumbnail is your mod's hero image.

quiz faq — questions & answers

A list of { "question", "answer" } pairs. Renders as an interactive accordion on your mod page.

extension add-on-of — declare your mod as an add-on

Numeric mod id of the parent mod. Your mod will appear in that mod's Add-ons section, and its sidebar will show a chip pointing back at the parent.

• check_circle Omit the field → whatever you set in the dashboard stays. Use it for a soft migration.
• check_circle Set to a positive number → mod becomes an add-on of that parent.
• check_circle Set to null → clears any existing parent (the mod becomes standalone).
• warning Unknown ids or self-references are skipped with a warning — the rest of the manifest still applies.

account_tree dependencies — per-release requirements

An object keyed by your mod's release tag. Each value is the list of required mods for that release, replacing whatever was previously recorded. Releases not listed are left untouched.

Resolves to the same constraint labels you see on the mod page:

• check_circle No bounds → "latest"
• check_circle release: "3.0.1" → exact pin: "3.0.1"
• check_circle fromRelease: "3.0.0" → "3.0.0+"
• check_circle toRelease: "3.5.0" → "≤ 3.5.0"
• check_circle fromRelease + toRelease → "3.0.0 → 3.5.0"

deployed_code install — OpenMods Manager rules

Tells the OpenMods Manager desktop app how to lay your release archive into the player's game folder. Without it, the Manager extracts the archive into the game root.

• check_circle No install block → archive contents drop into the game root, skipping any bundled .openmods/ folder.
• check_circle Only path → archive contents land under <path>/<mod name>/ so each mod gets its own subfolder.
• check_circle Only custom-path → mapped files/folders go to their exact destinations; the rest drop at the game root.
• check_circle Both → custom-path uses exact destinations for entries it covers; the rest fall under <path>/<mod name>/.