App Store Connect API basics for indie developers

Publishing an iOS app creates repeated App Store Connect work before review. You upload builds and keep release details current before submission.

The App Store Connect API can authenticate requests with JWTs and automate release tasks when App Store Connect work starts repeating. Start by signing JWTs. Script TestFlight first when beta management repeats. The API is optional for occasional releases, but it earns its setup cost when repeated App Store Connect work slows shipping.

What the App Store Connect API actually does

The API replaces repeated dashboard work with scripts once release operations start slowing your shipping rhythm.

Most dashboard work in App Store Connect can become scriptable. The API behind that is a standards-based REST API that automates tasks across Apple developer tools. It covers the release work most scripts need.

API changes affect live production data, so treat API automation with the same care as dashboard changes. A bad script can update real pricing or submit a real build.

The API groups its capabilities into functional areas. For a solo developer or small team, these areas make a practical starting point:

TestFlight: manage testers and groups. Assign builds and submit them to TestFlight App Review.
App metadata: create versions and set pricing by territory. Upload screenshots and submit for review.
Provisioning: manage bundle IDs and signing certificates. Track devices and provisioning profiles.
Sales and finance reports: download sales and financial reports. Pull analytics and usage data when your workflow needs them.
Customer reviews: retrieve reviews and post developer responses programmatically.

There are more areas, including In-App Purchases and Xcode Cloud. They also cover App Clips and Game Center. The groups above make a practical starting point for indie release automation.

How authentication works with JWT and API keys

Every API request requires a signed JSON Web Token (JWT). You generate that token from a private API key that you download from App Store Connect. The token proves who you are without sending a password on every call.

The key types differ in scope. Team keys access all apps, and the role you assign at creation scopes that access. Individual keys belong to one user. They cannot access Provisioning endpoints, Sales and Finance, or notaryTool. As a solo developer who is the Account Holder, a Team key gives you the broadest access.

Generating a Team API key

Create the key inside App Store Connect, then download the private file once. Follow these steps:

Go to Users and access → Integrations tab → App Store Connect API → Team Keys
Click Generate API Key or the + button
Enter a name and select a role for the key
Click Generate
Download the .p8 private key immediately

You can download the .p8 file only once, and Apple does not retain a copy. Save it somewhere safe and treat it like a password. Never store API keys in code repositories or include them in client-side code. You also cannot edit a key's name or role after creation. If you need a change, revoke it and create a new one.

Building and signing the token

The JWT splits into these parts:

Header
Payload
Signature

The header specifies the algorithm and your Key ID:

{
  "alg": "ES256",
  "kid": "2X9R4HXF34",
  "typ": "JWT"
}

The alg value must be ES256 for all tokens. The payload carries the fields App Store Connect needs to identify and time-limit the request:

{
  "iss": "57246542-96fe-1a63-e053-0824d011072a",
  "iat": 1528407600,
  "exp": 1528408800,
  "aud": "appstoreconnect-v1",
  "scope": ["GET /v1/apps?filter[platform]=IOS"]
}

Pay attention to exp. For most requests, tokens expire after a maximum of 20 minutes, which is 1200 seconds. Apple rejects requests with longer-lived tokens. After you sign the token with your .p8 private key, you include it as a bearer token:

Authorization: Bearer [signed token]

Apple allows longer-lived tokens in a narrow case. Tokens can last up to 6 months if they define a scope, include only GET requests, and target resources that support long-lived tokens. Those resources include:

Build Actions
Build Runs
Xcode Cloud Workflows
Power and Performance Metrics and Logs
Other Xcode Cloud-related resources

The endpoints indie developers use most

Practical automation usually starts with resource groups that remove repeated release work. You reach each group from the base URL api.appstoreconnect.apple.com. TestFlight management usually makes sense first because beta distribution repeats often.

The Prerelease Versions and Beta Testers group handles the full tester lifecycle, from adding testers to submitting builds for TestFlight App Review. If you push betas several times a week, removing that manual clicking saves meaningful time.

Customer review automation comes next for many builders. You can retrieve all reviews and post developer responses, which makes it easy to pipe new reviews into a Slack channel or monitoring dashboard.

Recent API additions help close older gaps:

Build Upload API: upload builds directly via REST, introduced at WWDC25. The flow works like this:
1. POST to create a BuildUpload.
2. Create a BuildUploadFile.
3. PUT the binary to the returned URL.
4. Notify App Store Connect.
Webhooks API: receive real-time push notifications for build changes and app version changes. It also covers TestFlight feedback events, which eliminates polling entirely.
Feedback API: retrieve TestFlight screenshot feedback and crash reports programmatically. Feedback records can include device info and crash logs.

Check official release notes before building automation that depends on a newly announced endpoint.

Setting up CI/CD with fastlane or Xcode Cloud

Continuous integration and delivery (CI/CD) turns API authentication into a repeatable release process. The right tool depends on whether you prefer scripts you control or workflows built into Apple's tools.

Common tools for indie CI/CD include fastlane and Xcode Cloud. fastlane is an open-source automation tool. Xcode Cloud is Apple's first-party service, and it is a strong option if you prefer to stay inside Apple's release workflow.

fastlane automates the release chain. It can handle:

Build version increments
Code signing and builds
App Store uploads
Changelogs
Review submission

It authenticates to the App Store Connect API with the Key ID and Issuer ID associated with the .p8 file.

A minimal release lane looks like this:

lane :release do
  app_store_connect_api_key(
    key_id: "D383SF739",
    issuer_id: "6053b7fe-68a8-4acb-89be-165aa6465141",
    key_filepath: "./AuthKey_D383SF739.p8",
    duration: 1200, # maximum
    in_house: false
  )
  pilot
end

The app_store_connect_api_key action sets a shared lane context value. Downstream actions like pilot, which handles TestFlight uploads, pick it up automatically. Other useful fastlane tools include deliver for App Store metadata uploads and match for certificate and profile management.

When Xcode Cloud makes sense

Xcode Cloud is built into Xcode. It runs automated tests, delivers builds to testers, and surfaces user feedback.

Setup is workflow-based rather than script-based. A basic workflow follows this order:

Add a test action.
Set start conditions for specific branches.
Add a post-action to distribute to TestFlight.

Pricing can make Xcode Cloud attractive for solo developers. You get 25 compute hours each month with Developer Program membership, while 100 compute hours each month costs US$49.99. For a single app with a modest release cadence, start with the free tier and measure usage before paying for more. Whether you script with fastlane or click through Xcode Cloud, both sit downstream of the actual publishing process.

Where the API fits in the publishing process

The publishing path works without the API, so do not automate before you understand the manual flow. Use the dashboard first if you ship rarely, then add scripts where repetition creates friction.

The full publishing path requires no API at all. Manual publishing has a clear order:

Enroll in the Apple Developer Program.
Set pricing.
Upload a build through Xcode.
Complete your metadata.
Submit for review.

Enrollment costs $99 per year for individuals. Organizations need a D-U-N-S number, which can take 1 to 2 weeks to receive.

After submission, your status changes to Waiting for Review. If App Review raises issues, you reply directly inside App Store Connect. After App Review approves it, the app may take up to 24 hours to go live.

Apple's September 10, 2025 release notes say you can create multiple draft submissions to stage updates before review. There are also build requirements to track. Since April 28, 2026, you must build apps with Xcode 26 or later using current SDKs.

The API pays off when manual work becomes repetitive:

Beta builds ship frequently and you want TestFlight management automated.
Real-time webhook notifications matter more than polling for build status.
Crash reports and TestFlight feedback need to flow into a separate tool.
Manual metadata updates have become tedious.

The API usually does not justify the setup if you ship occasional releases and the dashboard still feels manageable. For an AI app builder user who exports a project and ships manually, the standard path can work fine.

If you are still building the app itself, describe your idea in Anything, refine it through prompts, and ship. iOS deployment runs on Expo with cloud-signed App Store submission, so you can focus on the product before you automate release steps. Eligible developers may also qualify for the Small Business Program and a reduced Apple commission.

Rate limits and errors to plan around

Automation fails at the worst time if you do not plan for rate limits and errors. Add retries before you trust scripts with a release. Use logging and throttling so failures do not disappear.

Every API response includes an X-Rate-Limit header that tells you how many requests you have left. It looks like this:

X-Rate-Limit: user-hour-lim:3500;user-hour-rem:500;

The default is roughly 3,500 requests per hour per API key, though actual limits can vary. If your script exceeds it, the API returns a rate-limit error with the code RATE_LIMIT_EXCEEDED.

Log the failure, queue the job for retry, and throttle polling to stay under the cap. Webhooks help here, since they remove the need to poll at all.

Common failures to plan for include:

Bad request errors when retrieving daily sales reports
Authentication issues with JWT tokens and App Manager permissions
Not found errors when calling the appStoreReviewSubmissions endpoint in a fully automated release pipeline

Treat forum examples as field reports rather than guaranteed behavior. Build retry logic and clear logging into any automation from day one.

Start with the smallest useful automation

The App Store Connect API works best when it removes a repeated release task. Start with TestFlight automation if beta management takes the most effort, then add webhooks when polling becomes painful.

Keep occasional releases manual until the dashboard costs more time than the setup. If you are still shaping the app itself, build with Anything first, then automate release steps when your cadence justifies it.