Expo Application Services

Per bundle id (iOS) and package (Android) of a project: the distribution certificate and provisioning profile with their expiry, the App Store Connect API key for submissions, the push key, the upload keystore's fingerprints and the Google service account for submissions, and in words what is missing, expired or expiring within 30 days. Every identifier the project has credentials for or has built is covered, so one built without credentials shows up. No secret is ever read.

Cancel a build that is queued or running. EAS refuses one that has already ended, and says so; nothing else changes.

Cancel a workflow run that has not ended, with its running jobs (a build in progress stops spending).

Run an EAS workflow file at a git ref the project's GitHub repository already has. EAS reads the file and the code from GitHub; nothing local is uploaded. A build job spends EAS build credits; the summary line names the project, the file, the ref and each build job's platform and profile. Answers with the new run; follow it with get_workflow_run. Moves money or makes a legal document: the client asks the user to approve each call.

One build: its artifacts (the .ipa/.aab URL), fingerprint, runtime version, channel, timings and error. A build that ERRORED also carries failedStep, the step that failed and the line that says why, read from its log; steps lists them all.

A workflow job's log, by step: every step with its result and size, and the last lines of one step (the failed one by default). What eas workflow:logs --all-steps prints, without the noise.

One submission with Apple's or Google's error text; one that ERRORED also carries failedStep from its log (its own, or the workflow job's that made it); steps lists every step.

One workflow run with its jobs: each job's type, status and outputs (build_id, fingerprint hashes, app_build_version...) and artifacts. When it failed: reason in one line, and failures per job (the job's own error, which for an App Store upload is Apple's text, else its failed step and the line that says why); lines adds each failed step's tail.

Check that the Expo access token is present and accepted: which actor it is (a robot user, ideally), its accounts and the projects it sees. Reads only. Run this before concluding the server is broken.

A project's builds, newest first, filtered by platform, status, profile, bundle id or package, commit or fingerprint. Each says its status, profile, identifier, version and build number, commit, fingerprint, runtime, who started it and its error.

A project's fingerprints (the hash of its native side), newest first, or one by hash: how many builds and updates carry each, and the latest of them. Answers whether a build exists for a native state, the question a fingerprint-gated workflow asks.

The EAS projects this token can see, per account, with their full names (@account/slug) and ids: what every other tool's project argument takes. A tool may leave project out when the token sees only one.

A project's App Store Connect and Google Play submissions, newest first: status, the build (identifier, version, build number), the ASC app or Play track, the workflow job that made it, and error: Apple's or Google's own text (for a workflow's submission it lives on the job, which this reads).

A project's EAS Update channels with the branches they serve (production ones marked), and per branch the latest update for each platform and runtime version: what a device on that runtime downloads next.

A project's workflow runs, newest first, optionally of one workflow file, status or ref: status, ref, commit, trigger (a GitHub push, a schedule, a dispatch) and who. A FAILURE run carries reason: the failed job, its failed step and the line that says why, read from the job's log (e.g. "submit_ios > Prepare credentials: eas-cli failed to resolve submission config ...").

A project's EAS workflow files (.eas/workflows/*.yml), by file name: what list_workflow_runs and dispatch_workflow take.

Put an existing update group on a branch again, as eas update:republish does: roll a branch back to an earlier group, or promote a group from one branch to another. Nothing is uploaded. Refuses a group of another project, a code-signed group or one in a rollout, and with expect_commit a group published from another commit. Answers with where the group came from (its branch, commit and message) and the new group.

End an update group's rollout by sending every device on its branch and runtime back to the update before it, as eas update:revert-update-rollout does: that update's group is published on the branch again, ending the rollout; nothing is deleted or uploaded. Refuses a rollout something newer already ended, and one with no update before it (the app's embedded update; revert that with eas-cli in the project). Answers with the groups republished and the production channels.

Raise an update group's rollout to a percentage of the devices on its branch and runtime, as eas update:edit does; 100 rolls it out to every device and ends the rollout. A rollout only grows (revert_rollout takes it back); setting what it already is changes nothing. Answers with the percentage before and after, and the production channels that serve the branch.

Set (or clear) the App Store Connect API key EAS uses to submit one iOS bundle id, as eas credentials does. Without one, eas submit and a workflow's submit job fail at Prepare credentials. Answers with the key before and the bundle's audit after.

Submit an existing FINISHED build: iOS to App Store Connect (TestFlight), Android to a Google Play track. It uses what EAS holds for the build's own bundle id or package (the ASC key or Google service account set for submissions, as audit_credentials shows it), so it fails before scheduling anything when that is missing. Spends no build credits. Give expect_version or expect_build_number when you know what should ship: a build that differs is refused. Answers with the build as submitted (platform, profile, app version, build number, commit) and the submission; follow it with get_submission.

Check an EAS workflow file before it runs, the way eas workflow:validate does, without a checkout: the file as the project's repository has it at a ref (workflow and git_ref; EAS reads it from GitHub, as a dispatch would), or a file (path). Answers valid, the issues (YAML that does not parse, a needs: naming no job, and every problem EAS's own validator names, field by field), the jobs, and the build jobs a dispatch would spend credits on. Runs nothing, spends nothing. Never type or paste a file's base64 yourself: a retyped file can arrive changed. Give the path of a file in your workspace folders (the roots this client shares; without them /workdir), or have a script that read the file send content_base64 with its sha256.

Wait until a workflow run or a build ends (give run or build), looking every 15 s, and answer as get_workflow_run or get_build would then: the outcome and, when it failed, the reason. While it waits, a client that asks for progress hears where it stands (jobs done, the job running). A run that waits for someone's approval, or one still going after minutes, answers done: false with its state; cancelling the call only stops the waiting, never the run.