Open-source clients

i3deploy's public contract is the JSON manifest, not a proprietary widget or SDK. Anything that can do a GET and parse JSON can render a changelog from it — a static site, a mobile app, a Slack bot, a curl | jq one-liner in a build script. There's no official client library you're required to use, and that's on purpose: the feed is the product.

A minimal consumer

const res = await fetch(
  "https://storage.googleapis.com/i3deploy-public/<org>/projects/<slug>/releases.json"
)
const { releases } = await res.json()

for (const release of releases) {
  console.log(`${release.version} — ${release.name} (${release.released_at})`)
  console.log(release.short_summary)
  // release.changelog_markdown is Markdown — render it with any Markdown library
}

That's the whole integration: one fetch, no auth, no SDK. Keep the request a plain GET with no extra headers — see the CORS note on the manifest page for why. From here, plug releases into whatever you already use to render lists — a "what's new" panel, a toast on first login after a new release, a public changelog page — the manifest doesn't care who's reading it or how.

Where django-i3version fits in

django-i3version is a separate, sibling open-source project — a standalone, reusable Django app (pip install django-i3version) for tracking an application's own release versions and fanning out per-user "there's a new version" notifications inside a Django project. It has its own models, its own API, and its own history — it does not import from or depend on i3deploy-back.

To be precise about where things stand today: django-i3version is not yet a drop-in consumer of the i3deploy public manifest documented on this page. It doesn't currently fetch releases.json or render an i3deploy changelog out of the box. It's the sibling project that's on track to become the reference open-source client for this manifest — a future version would poll a project's releases.json and use it to drive the same per-user notification flow it already has for its own, locally-created Version rows. Until that lands, the two projects are related in intent (both model "a release happened, tell people about it") but not wired together in code.

If you want release-tracking + per-user notifications inside your own Django project today, django-i3version works standalone against its own API — see its README for INSTALLED_APPS setup and the publisher API. If you want to consume i3deploy's manifest specifically, the minimal snippet above is all you need — no need to wait for the two to converge.

Next

• The public manifest — the full JSON contract, CORS behavior, and a real sample response.
• Cutting releases — how releases get published in the first place, on the i3deploy side.