Skip to content
Titanium SDK

Registry API

The module registry as JSON, for the Titanium CLI and anything else that wants it. Generated at build time and served as static files, so it is safe to call often and safe to cache. Reads are open cross-origin.

Endpoints

  • GET /registry/v1

    Index

    What this API serves, and the resolution rules below in machine-readable form.

  • GET /registry/v1/modules

    Every module

    One file, official and community together, each tagged with a kind. There are no query parameters - the whole list is small enough to fetch and filter locally, which is why it can be cached whole.

  • GET /registry/v1/modules/{moduleId}

    One module

    Its current release per platform, and every release it has ever published.

  • GET /registry/v1/modules/{moduleId}/v/{version}

    One release

    The platform manifests, and the archive to download for each platform.

  • GET /registry/v1/releases

    SDK releases

    Every published Titanium SDK release (GA, release candidates and betas) with the per-OS archives.

  • GET /registry/v1/branches

    CI branches

    The branches with builds worth offering. Counts are recomputed rather than read from the committed map, because CI artifacts expire 90 days after their run.

  • GET /registry/v1/branches/{branch}

    CI builds

    One branch’s builds. A build whose artifacts have expired is never listed - its download URL would 404.

The paths mirror the pages, so one is guessable from the other: /modules/ti.map/v/5.7.0 is a page and /registry/v1/modules/ti.map/v/5.7.0 is its JSON. The full list is currently 54 KB across 163 modules.

Compatibility paths

The Titanium CLI reads these, and older copies of it stay in use for years, so they keep answering in their original shape - a bare array, or a bare object for the branch counts. They are served rather than redirected: the CLI does not follow redirects. Prefer the versioned endpoints above for anything new.

  • /registry/branches.json
  • /registry/{branch}.json
  • /registry/ga.json
  • /registry/rc.json
  • /registry/beta.json

Resolving a version

A Titanium module is not an npm package. Releases are per platform, and picking the wrong one fails quietly rather than loudly, so these rules are part of the contract. They apply to modules; an SDK release is one build per OS and needs none of this.

  • A module has a current release per platform, never one overall. Read `latest[platform]` for the platform you are building.
  • Do not compare versions across platforms. ti.map is android 5.7.0 and ios 7.3.1 at once, and neither supersedes the other.
  • A release may carry both platforms. When it does, the same version appears under each key.
  • `minsdk` is the Titanium SDK a release requires, copied verbatim from that platform manifest. It is not normalised: expect both "12.7.0" and "10.0.0.GA", sometimes on the same module, so strip any suffix before comparing. Absent means the manifest did not declare one.
  • Entries with `"kind": "community"` are repositories, not packages. They carry no version list and nothing to install.
  • `kind` is whether this site has a page for a module; `source` is who stands behind it. They are not the same question: a repository owned by TiDev that nothing here documents is `"kind": "community"`.
  • `source` is one of three. `tidev` means TiDev maintains it and this site compiles its reference. `community` means TiDev has reviewed the repository and vouches for it, without hosting anything. `unverified` means it was found by its `titanium` topic and nobody has reviewed it - which is most of them. Only `tidev` implies anything about the code.
  • Being listed is not an endorsement. An `unverified` entry is a search result, and the bar for appearing at all is a `titanium` topic plus a platform directory. Archived repositories and forks are excluded.

Known gaps

  • Checksums are not upstream attestations. Every asset carries checksum as sha256:<hex>. 16 of them are the digest GitHub recorded at upload; the other 363 were computed by downloading the archive, because GitHub only began recording digests in September 2025 and does not backfill. Both record what GitHub served, not an independent signature, so a checksum detects corruption in transit and any later change to an archive - it does not prove the archive was untampered before it was recorded. Still treat a missing checksum as “cannot verify”, never as “verified”.
  • Community entries are repositories. They are listed so a search can find them, but they carry no version list and nothing to install. Only "kind": "registry" entries are installable.

Stability

The version lives in the path. Fields may be added to v1 responses; nothing will be removed or change meaning. A breaking change gets a new path segment, and this one keeps answering - CLI copies stay in the wild for years.