App Store Connect makes you pick a role the moment you create an API key, and then tells you very little about what that choice bought. Some endpoints answer for a Finance key and refuse an App Manager one. Some do the reverse. The role you want depends on the calls you are going to make, and the calls you are going to make are documented one at a time.
The awkward part is that a key will never tell you what it is. App Store Connect exposes no role on the key resource. There is no whoami, no field to read, no way to ask. You send a request and read the status code back, and that is the whole of the available method.
So we sent the requests. Four keys were issued on one developer account, one per role, and each was aimed at every endpoint a portfolio analytics app touches. Below is what came back.
The measured table
The first five rows were measured 2026-07-26, the last three added 2026-08-13, on one account. 403 is Apple's The API key in use does not allow this request. 404 means the endpoint answered and had nothing to return.
| Endpoint | Admin | Finance | Sales | App Manager |
|---|---|---|---|---|
| GET /v1/apps | 200 | 200 | 200 | 200 |
| GET /v1/salesReports | 200 | 200 | 200 | 403 |
| GET /v1/financeReports | 404 | 404 | 403 | 403 |
| GET /v1/subscriptionGroups | 200 | 403 | 403 | 200 |
| GET /v1/apps/{id}/customerReviews | 200 | 200 | 200 | 200 |
| POST /v1/subscriptionPrices | 409 | 403 | 403 | 409 |
| POST /v1/analyticsReportRequests | 201 | 403 | 403 | 403 |
| GET /v1/apps/{id}/analyticsReportRequests | 200 | 200 | 200 | 403 |
The two 409 answers in the pricing row were deliberate. That call was probed with a price point id that cannot exist, so nothing was applied to a real product. A 409 there means Apple accepted the key and rejected the body, which is the answer we wanted: the scope is held. Finance and Sales did not get that far.
Roles are axes
The single most useful thing in that table is the shape of it. Nobody sits at the bottom. Finance reads sales reports, finance reports and the app list, and cannot see the subscription catalog at all. App Manager edits the catalog and cannot read a single sales report. Only Admin reaches both sides.
Which means the question “what is the lowest role that will work?” has no answer. There is only the set of calls your tool makes, and whether one role covers all of them.
Four rows worth knowing about
App Manager cannot read sales
This is the one that catches people, because App Manager is the role most developers hand out. It writes app metadata, uploads builds, edits the subscription catalog, and gets a flat 403 on /v1/salesReports. A tool built on an App Manager key can change your prices and cannot tell you what they earned.
Finance and Sales cannot see the subscription catalog
/v1/subscriptionGroups refuses both of them. Any feature that shows a plan's display name, its duration, or the price you set in a given territory needs Admin or App Manager, even though the revenue those plans produced is readable with a Finance key.
Reading reviews works on every role
You might expect reading reviews to need App Manager. All four keys answered 200 on /v1/apps/{id}/customerReviews. If a setup guide tells you to create a second key so a dashboard can show your reviews, that guide is costing you a key. Replying to a review is a POST and was left untested, so it may still be narrower.
A 404 from financeReports is not a refusal
Financial reports come into existence when Apple issues an actual payment. Before your first payout, every month and every region answers 404 There were no sales for the date specified, on a key with exactly the right role. A newly launched developer will see that 404 for months and it will be correct every time.
Two details make debugging that endpoint less miserable. A wrong vendor number is rejected outright with a 400, so a 404 tells you the vendor number is right. A wrong region code is not rejected, and 404s exactly like an empty period, so a region typo is invisible.
The Analytics Reports API has its own axis
Apple's newer Analytics Reports API, the one behind /v1/analyticsReportRequests, splits along a different line again. Creating the report request is Admin only. Finance and Sales both get 403 on the POST, then read the entire chain of an Admin-created request without a single refusal: request list, reports, instances, segments, and the signed segment download. App Manager is refused at every step, including the reads.
The practical consequence is that one Admin call, made once, unlocks the whole catalogue for keys that could never have made it. A live request lists 156 report types.
One trap in there is expensive. ONE_TIME_SNAPSHOT backfills to the day the app was created, which is exactly what you want, and you get roughly one per 31 days. Deleted requests count against that allowance. Create one to see what it does, delete it, and you have spent the month. Use ONGOING while you are still working out what you need.
Also worth knowing: Apple stops generating reports nobody downloads. A request that has been sitting there unread comes back marked stoppedDueToInactivity.
Picking a role
If you are creating a key for a dashboard that reads revenue and users, Sales and Reports is enough right up until the moment you want a payout figure, and then it is a 403 you cannot fix without issuing a new key. Finance covers the reports and the payouts and stops at the catalog. Admin covers everything, which is why tools that read prices and plan names ask for it.
Whatever you pick, probe it. Do not trust a table, this one included. Roles get revised, and a key that authenticates has told you nothing about what it will answer.
How StudioDash handles this
StudioDash asks for one key and probes it at connect time, so a feature that your role cannot reach says so in its own place instead of failing silently later. Reads run on your device, straight to Apple, and the key stays in the iPhone Keychain.
