Public API

Read-only JSON under /api/v1, no login needed. Lists and the manifest hold public addons and packs; an unlisted addon or pack is read by its address, as on the website. Responses carry an ETag and Cache-Control: public; send If-None-Match to get cheap 304s.

GET /api/v1/manifest.jsonCatalogue: every public addon with its latest version per channel, package URL and SHA-256. Refreshed every five minutes.
GET /api/v1/addonsListing with filters.
GET /api/v1/addons/{slug}Addon details.
GET /api/v1/addons/{slug}/releases/{version}Release, modules, dependencies and install closure.
GET /api/v1/collections/{slug}A pack at its published revision, with the number of items you cannot see.

Private addons in the launcher

A player signed in to the launcher sees the private addons and packs they are a member of. The launcher gets a short-lived addons token from WarAccounts and sends it as Authorization: Bearer … to /api/v1/me/…: manifest.json (what membership adds to the catalogue), collections (packs you own or were added to) and the same addon, release, pack and comment reads as above. A private package is fetched with POST /api/v1/me/addons/{slug}/releases/{version}/download, which returns a link that works for ten minutes. These answers are never cached. They take the launcher's token, not a personal API token.

Write API and CI uploads

Create a personal token under API tokens and send it as Authorization: Bearer ror_…. Uploads go through the same verification pipeline as the web form: the response is 202 with a status URL to poll, and the release is published automatically only when you are a trusted maintainer of the addon.

GET /api/v1/meThe token's owner, scopes and the addons it may act on.
POST /api/v1/addons/{slug}/releasesMultipart upload: version (semver), package (zip), optional changelog_md. Scope releases:write.
GET /api/v1/addons/{slug}/releases/{version}/statusPipeline status and check results, including unpublished releases. Scope releases:read.

curl

curl -sS -H "Authorization: Bearer $ROR_TOKEN" \
  -F version=1.2.3 -F [email protected] -F [email protected] \
  https://addons.returnofreckoning.com/api/v1/addons/my-addon/releases

GitHub Actions

Push a tag such as v1.2.3. Add the token as the repository secret ROR_TOKEN. The registry writes the version and release date into every .mod, so leave version="@project-version@" in your source.

name: Publish to RoR addons
on:
  push:
    tags: ['v*']
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Package
        run: |
          VERSION="${GITHUB_REF_NAME#v}"
          zip -r "$RUNNER_TEMP/addon.zip" . -x '.git*' '.github/*'
          echo "VERSION=$VERSION" >> "$GITHUB_ENV"
      - name: Upload
        run: |
          curl -sSf -H "Authorization: Bearer ${{ secrets.ROR_TOKEN }}" \
            -F "version=$VERSION" -F "package=@$RUNNER_TEMP/addon.zip" \
            https://addons.returnofreckoning.com/api/v1/addons/${{ vars.ROR_ADDON }}/releases

GitLab CI

publish:
  stage: deploy
  image: alpine:3
  rules:
    - if: $CI_COMMIT_TAG =~ /^v/
  script:
    - apk add --no-cache curl zip
    - VERSION="${CI_COMMIT_TAG#v}"
    - zip -r addon.zip . -x '.git*'
    - curl -sSf -H "Authorization: Bearer $ROR_TOKEN" -F "version=$VERSION" -F "[email protected]" https://addons.returnofreckoning.com/api/v1/addons/$ROR_ADDON/releases

Without CI: link the repository from the addon's manage page and the registry pulls each tag itself.