Most of App Store Connect is automatable, and more of it than people assume. Metadata, screenshots, builds, pricing across every territory, in-app purchases, subscriptions with introductory offers, phased release, review submission: all of it has endpoints, and all of it works. The awkward part is the small set of things that do not, because they are not listed anywhere as a set. They are discovered.
There are two kinds of wall here. Most are Apple's: an endpoint that does not exist, or exists and refuses API keys. One is ours, and it is marked as ours. Each entry says what breaks, what comes back, and what to do instead.
Create an app record
POST /v1/apps, for every key and every role.The app record is the one thing that must be made by a human in the website. There is no supported way to create it with an API key, and there never has been. Probing the collection confirms the shape of the restriction: the apps resource answers GET and PATCH, and nothing else.
In practice this is a once-per-app annoyance rather than a blocker, but it does mean the sentence "fully automated first release" is not true for anyone, whatever tooling they use. The first release always has a human in the website for about ninety seconds.
App Store Connect website, Apps, the plus button. Bundle ID, SKU and primary language. Everything after that is writable over the API.
Delete an app record
DELETE /v1/apps. Builds and appInfos cannot be deleted either.Removing an app is the most misunderstood item on this list, because the automatable half and the manual half are not where people expect. Taking the app off sale everywhere is fully automatable, and Apple requires it even for an app that was never released: set availability to an empty territory list, which switches off all roughly 175 territories, and remove any in-app purchases from sale as well.
Only the last step is manual, and it has conditions worth knowing before you start:
- App Information, Additional Information, Remove App, in the website.
- Account Holder or Admin role. It is not visible to anyone else.
- It is also not visible while the app sits in Ready for Review, Waiting for Review, In Review, Metadata Rejected or Rejected. Cancel the submission first, or wait.
- The SKU can never be reused anywhere in the organisation. The bundle ID cannot be reused either, if a build was ever uploaded against it.
Automate the off-sale sweep, then do the removal by hand. The two reuse rules are permanent, so pick the SKU of a throwaway app as carefully as a real one.
Submit an app's first in-app purchases
FIRST_NON_CONSUMABLE_MUST_BE_SUBMITTED_ON_VERSION, with the equivalent for each product type.This one catches people who have already automated everything else, because creating the product works perfectly. Price, availability, localisations, review screenshot, state moves to Ready to Submit. Then the submission is refused, and the reason is that Apple wants an app's first products of a type reviewed together with a version, and only the website can put the two into one submission.
The failure matters more than it looks, because a half-done submission can orphan the version. Our submit_for_review detects the condition and aborts before it submits anything, rather than discovering it halfway.
Configure the products over the API, then open the version in the website, use Add for Review, tick the products and submit them together. Every later product submits over the API normally.
Fill in the app privacy nutrition label
appDataUsages is not in the public API at all.The privacy questionnaire, the one that produces the data-collection card on your product page, has no public endpoint. It is not a permissions problem and no key unlocks it; the resource is simply not published.
It also cannot be skipped: an app without it will not pass review. Since the answers are stable across releases, the honest automation is to be told exactly which boxes to tick, once, rather than to pretend the call exists.
Website, App Privacy. Our set_privacy_nutrition returns the exact checklist for your app and a deep link to the page, so the manual step is a two-minute one.
Declare EU Digital Services Act trader status
Since the DSA came into force, an app distributed in the EU needs a trader declaration with a verified name, address and contact details. There is no API attribute for it, and arguably there should not be: it is a legal statement about who is selling, not a setting.
Leaving it undone eventually removes the app from EU storefronts, which is a slower and more expensive failure than a rejection.
Website, Business, Trader Status. set_eu_trader_status returns the steps and the deep link. The decision is yours and your accountant's.
Create an App Group
App Groups, the identifier two of your own targets need to share a container, live in the Apple Developer portal rather than in App Store Connect, and that portal has no equivalent API surface. Neither does the capability wiring that goes with them.
Apple Developer portal, Identifiers. Once per group, and it outlives every release.
Create a signing certificate, or use cloud signing
This one is a consequence of doing the right thing. An API key scoped to what a release needs does not carry certificate rights, so requesting a distribution certificate through it fails, and cloud signing fails with it. A key that could mint signing identities would be a considerably more dangerous thing to keep in an agent's environment.
Keep an Apple Distribution certificate in the login keychain, and generate manual-signing profiles and an ExportOptions.plist against it. setup_app_store_signing does that part.
Compile the binary
Obvious when stated, and still worth stating, because it is the reason a release cannot run entirely in the cloud: producing an .ipa needs the Xcode toolchain on a Mac. The API accepts the upload, it does not perform the build.
Archive and export locally, then upload. The upload, the processing wait and the attachment to a version are all automatable.
Post a public response to a review
Reviews, ratings and their territories all come back over the API, which is what makes reading them in an agent worthwhile. Publishing the reply does not, so the last step is a paste into the website.
Of everything here this is the one that costs the most real time, because a reply is exactly the kind of writing that benefits from happening where the context already is.
Draft it where the review is, paste it in the website. draft_review_response writes it; you post it.
Capture simulator screenshots, in our tools
Uploading screenshots is fully automatable, and we automate it. Producing the PNGs from a simulator is on our roadmap and not built, so today you bring your own images. It is on this list because a list of walls that quietly omits the author's own is not worth reading.
Produce the PNGs however you already do, then upload_screenshots handles sizing, ordering and the per-locale sets.
Possible, and not obvious
These are not refusals. They are the places where the API does exactly what you asked and the result is not what you wanted.
- An app has more than one appInfo, and Apple hands you the wrong one first. An app that is live or in review keeps a locked appInfo alongside the editable one, and the collection returns the locked record first. Anything that takes the first row, or asks for
limit=1, gets the one that cannot be written, and the PATCH comes back 409. Select the editable record explicitly. - Subscription state does not recompute on its own. An in-app purchase becomes Ready to Submit the moment price, availability and a review screenshot are in place. A subscription does not: it needs availability first, then the USA base price, then equalisation across the roughly 175 territories, then any per-territory introductory offers, and then a no-op PATCH to make the state recompute. Same product family, different behaviour.
- Availability defaults to everywhere. Creating something without naming territories makes it available in all of them. That is usually what you want and occasionally very much not, and it is the same lever you need to pull to an empty list when you are removing an app.
Can you create an app record with the App Store Connect API?
No. POST /v1/apps is refused for API keys, whatever role the key holds. The app record has to be created once in the App Store Connect website, after which everything about it is writable over the API. There is no supported automation for that first step, and there has not been one since the API launched.
Why does submitting an in-app purchase return FIRST_NON_CONSUMABLE_MUST_BE_SUBMITTED_ON_VERSION?
Because it is the app's first in-app purchase. Apple requires the first products of a type to be reviewed together with an app version, and only the website can bundle the two into one submission. Create and configure the product over the API as normal, then submit it from the version page in the website. Every product after the first submits over the API without complaint.
Can the App Store Connect API set the app privacy nutrition label?
No. The data-collection answers live behind appDataUsages, which is not part of the public API, so the privacy questionnaire is website-only. The same is true of the EU Digital Services Act trader declaration, which has no public attribute at all and is a legal statement about who you are rather than a setting.
Can you reply to an App Store review through the API?
You can read reviews and ratings over the API, and you cannot post the public reply. Drafting the response is automatable, pasting it is not. This is the one limit on the list that costs real time, because review responses are the part of App Store Connect that actually benefits from being written where the context is.
Where this list comes from
It is not written by hand. Every entry above is generated from the tool definitions in asc-mcp, an MCP server that drives App Store Connect from a coding agent: 41 tools that either do the thing over the API or, for the ten above, return the exact manual steps and stop cleanly rather than leaving a release half-done.
Six tools work with no licence, three of those without any Apple credentials, and a seven-day trial of the rest starts from inside your agent with no card. If you only came for the list, the list is in the repo too, and it moves whenever Apple does.
The other piece of writing here is about the billing behind it: seven ways a license server quietly cuts off paying customers.