Product docs

What Synton actually does.

Synton is a release metadata service for Android apps. It sits between your CI, GitHub, and Google Play so a build can be linked to the commits that created it, the version policy that named it, and the Play track where it currently lives.

Version as a service

Ask Synton for the next version name during CI, based on the previous known build and commit messages.

Release ledger

Keep the version, version code, commit range, bump type, generated notes, and source SHA together.

Google Play tracks

Sync current track state and promote known version codes across Play tracks.

Version as a service

The CI asks for a version. Synton returns a decision.

The core API is intentionally small. Your build pipeline tells Synton which app and commit it is about to build. Synton reads the GitHub commit range, applies the configured versioning policy, saves the result, and returns the version metadata your Android build can stamp into the app.

Your CI sends the build context

Synton receives the Android package name, the current branch, and the commit SHA that should become the next app version.

Synton reads the GitHub commit range

It compares the previous known build commit, or the configured base SHA for the first build, with the requested commit.

A bump policy is applied

Breaking changes bump the major version, feat: commits bump the minor version, and every other non-empty commit range bumps the patch version.

The build becomes part of the release trail

Synton stores the version name, version code, bump type, commit list, generated notes, branch, and source commit.

Request contract

commit

Required. Full or resolvable commit SHA for the build.

branch

Required. Currently only main is accepted for release builds.

bundle_id

Optional if a default app exists, but recommended in real CI.

Response contract

version

The next Android version name, for example 1.8.4.

version_code

The generated version code for the stored Synton build.

bump_type

major, minor, or patch.

commits

The GitHub commits used to decide the bump.

notes

A deterministic changelog generated from the commit messages.

Example CI call

curl -X POST https://synton.app/api/builds \
  -H "Authorization: Bearer $SYNTON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "bundle_id": "app.synton.demo",
    "branch": "main",
    "commit": "8f31c2a9b7..."
  }'

CI integration

A minimal GitHub Actions flow.

The first integration does not require Synton to build the app. Synton only decides the Android version, then your existing Gradle build consumes that decision.

Create the Android app in Synton and configure its package name.

Configure the GitHub repository, base SHA, and GitHub token in app settings.

Store SYNTON_API_KEY as a CI secret.

Call POST /api/builds before the Android build step.

Pass the returned version and version code into Gradle.

- name: Ask Synton for Android version
  id: synton
  run: |
    response=$(curl -sSf -X POST https://synton.app/api/builds \
      -H "Authorization: Bearer ${{ secrets.SYNTON_API_KEY }}" \
      -H "Content-Type: application/json" \
      -d "$(jq -n \
        --arg bundle_id "app.synton.demo" \
        --arg branch "${GITHUB_REF_NAME}" \
        --arg commit "${GITHUB_SHA}" \
        '{bundle_id: $bundle_id, branch: $branch, commit: $commit}')")

    echo "version_name=$(echo "$response" | jq -r .version)" >> "$GITHUB_OUTPUT"
    echo "version_code=$(echo "$response" | jq -r .version_code)" >> "$GITHUB_OUTPUT"

- name: Build Android app
  run: ./gradlew assembleRelease \
    -PversionName="${{ steps.synton.outputs.version_name }}" \
    -PversionCode="${{ steps.synton.outputs.version_code }}"

Google Play workflow

Google Play remains the runtime authority.

Synton does not replace the Play Console. It records what Google Play says is active, links known version codes back to Synton builds, and can apply controlled promotions using the Android Publisher API.

Track sync

Synton opens a temporary Google Play edit, reads internal, alpha, beta, and production tracks, then stores the current active version for each track.

Implemented

Track promotion

Synton can promote an existing version code to a target track, commit the Play edit, and immediately sync Google Play state back into the dashboard.

Implemented, needs hardening

Release notes per track

Synton can generate plain-text Play Store notes by comparing the latest build with the build currently active on a target track.

Early implementation

Current limits

Useful today, still intentionally narrow.

These limits keep the product understandable while the first release workflow gets hardened.

Only GitHub is supported as a commit source.

Only the main branch is accepted by the version API today.

The version code is generated from the number of stored Synton builds, not from Google Play's highest existing version code.

Synton does not build or upload APK/AAB artifacts.

Promotion uses an existing Google Play version code. The artifact must already exist in Google Play.

Promotion currently uses completed releases from the dashboard path; staged rollout controls can come later.

Generated release notes are deterministic and commit-based. Human or AI rewriting is a later layer.

Recommended next build step

Make the version API easy to try from a real CI job, then harden the Play track dashboard around known and unknown version codes.

Open dashboard