Developer Experience

The OrbitKit CLI: App Store web compliance from your terminal and CI

Generate, configure, and deploy your privacy policy, AASA file, support page, and more from the command line — scriptable for CI/CD. The OrbitKit CLI reference.

By · · 7 min read

If you ship iOS apps from a CI pipeline, the web side of App Store compliance shouldn’t be the one manual step that breaks the automation. The OrbitKit CLI wraps the same API the dashboard uses, so your privacy policy, AASA file, support page, data-deletion page, and privacy manifest can be generated, configured, and deployed from a terminal or a CI job.

This is the practical reference: install, auth, the command surface, and a CI example.

For what these files are and why Apple requires them, see every URL and file Apple requires for an iOS App Store submission.

Install

The CLI ships as an npm package, Node ≥ 22:

npm install -g orbitkit
# or run without installing
npx orbitkit --help

Authentication

No stored credentials — auth is a single environment variable, which is exactly what CI secret stores expect:

export ORBITKIT_API_KEY="ok_live_…"   # create one in the dashboard → Settings → API Keys
export ORBITKIT_APP_ID="…"            # optional default; or pass [appId] per command

The API key is sent as a Bearer token over HTTPS. Nothing is written to disk.

The command surface

orbitkit --help

whoami                  Show current user info (verifies API key)
apps                    Manage apps (list, etc.)
deploy [appId]          Deploy site to production
deploy-history [appId]  Show deploy history
policy                  Manage privacy policy (get / set)
site                    Manage site config (get / update / icon / domain / custom-html)
support                 Manage support page (get / set)
deletion                Manage data deletion page (get / set)
aasa                    Manage Apple App Site Association (get / set)
privacy-manifest        Manage PrivacyInfo.xcprivacy (get / set / sync / download / reference)
banner                  Manage Smart App Banner (get / set)
well-known              Upload well-known files (SIWA, Apple Pay, Wallet)
testflight              Manage TestFlight landing page (get / set)

Every command takes --json for machine-readable output (pipe into jq), and --debug to print the requests.

Typical workflows

Verify auth in a CI preflight

orbitkit whoami --json | jq -e '.email' >/dev/null \
  || { echo "OrbitKit auth failed"; exit 1; }

Round-trip a config file (the get → edit → set pattern)

orbitkit policy get "$ORBITKIT_APP_ID" --json > policy.json
# edit policy.json in your repo / via a script
orbitkit policy set "$ORBITKIT_APP_ID" policy.json

The set [appId] <file> shape is consistent across policy, support, deletion, aasa, banner, and privacy-manifest — they all take a JSON file argument, so you can keep your App Store web config in version control next to your app code.

Pull the privacy manifest into your Xcode project

orbitkit privacy-manifest download "$ORBITKIT_APP_ID" \
  -o ios/App/PrivacyInfo.xcprivacy

Wire that into a build phase and your PrivacyInfo.xcprivacy is regenerated from the same source of truth as your hosted privacy policy — no drift, no ITMS-91053 surprises.

Deploy as the last step of a release pipeline

orbitkit deploy "$ORBITKIT_APP_ID"
# Deployed: https://sites.orbitkit.io/your-app

GitHub Actions example

name: Sync App Store web compliance
on:
  push:
    branches: [main]
    paths: ["app-store/**"]
jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: npm install -g orbitkit
      - name: Push policy + AASA, then deploy
        env:
          ORBITKIT_API_KEY: $
          ORBITKIT_APP_ID: $
        run: |
          orbitkit policy set "$ORBITKIT_APP_ID" app-store/policy.json
          orbitkit aasa set "$ORBITKIT_APP_ID" app-store/aasa.json
          orbitkit deploy "$ORBITKIT_APP_ID"

Now your privacy policy and AASA file live in the repo, change through pull requests, and deploy on merge — the same workflow as the rest of your app.

Exit codes

The CLI uses distinct exit codes so CI can branch on the failure type — e.g. missing API key vs. network error vs. validation error — rather than parsing stderr. Run with --debug to see the request/response and the X-Request-Id for support.

Create an API key in the dashboard to get started — start free or see the full feature list.