reviewSubmissions concurrency limit (CONCURRENT_REVIEW_SUBMISSION_LIMIT_EXCEEDED) - correct batching strategy?

Question

Created 3w

Replies 1

Boosts 0

Participants 2

We are automating subscription review submissions via the App Store Connect API (POST /v1/reviewSubmissions, /v1/reviewSubmissionItems) for an app with many creator-defined in-app subscriptions (App ID: 6777003020). We would appreciate clarification on the following, as the public documentation appears inconsistent with what we observe in production:

What is the actual concurrency limit, and does it vary?

We received this live error when calling POST /v1/reviewSubmissions:

{ "status": "409", "code": "STATE_ERROR.ENTITY_STATE_INVALID", "detail": "This resource cannot be reviewed, please check associated errors to see why.", "meta": { "associatedErrors": { "/apps/6777003020": [{ "status": "409", "code": "STATE_ERROR.CONCURRENT_REVIEW_SUBMISSION_LIMIT_EXCEEDED", "detail": "Unable to create reviewSubmission for appId=6777003020 reviewSubmissionType=DEFAULT platform=ANY as maximum limit=5 of concurrency has reached" }] } } } This says the limit is 5. However, your public documentation ("Overview of submitting for review") states: "A platform can have a maximum of two submissions under review at a time: one that includes an app version and one that includes items… without an app version." Could you confirm:

Is 5 the correct, current limit for item-only (reviewSubmissionType=DEFAULT, no app version) reviewSubmissions specifically for in-app purchases/subscriptions? Does this limit scale with account size, app size, or number of in-app purchases, or is it a fixed platform-wide constant for every developer account? Is this the same quota referenced by the deprecated subscriptionSubmissions resource's undocumented SUBMISSION_LIMIT_REACHED error, or an entirely separate one? 2. What counts against the limit, and for how long?

Does a reviewSubmission count against this limit from the moment it's created (READY_FOR_REVIEW), or only once actually submitted (WAITING_FOR_REVIEW/IN_REVIEW)? If we create a reviewSubmission and never call submitted:true on it, does it still occupy a slot indefinitely, or does Apple expire/release it automatically after some period? Is there a reliable, documented way to cancel/release a reviewSubmission via the API to free a slot on demand, and is that guaranteed to complete promptly? (We're aware of forum reports of CANCELING state persisting for extended periods without resolution.) 3. Can this limit be raised for our account? Is there a process (support request, account tier, or otherwise) to request a higher concurrency limit for automated review submissions, given we manage subscriptions on behalf of many independent creators?

Proposed workaround — please confirm whether this resolves the issue:

Per your documentation, a single reviewSubmission can hold up to 200 reviewSubmissionItems. Our proposed fix is to stop creating one reviewSubmission per subscription, and instead:

Check for an existing, still-editable (READY_FOR_REVIEW) reviewSubmission for the app. If one exists, add the new subscription as an additional item to it (up to the 200-item cap) rather than creating a new reviewSubmission. Only create a new reviewSubmission when none exists in a state that still accepts new items. Could you confirm whether this is in fact the intended/correct usage pattern to stay under the concurrency-5 limit — i.e., does batching multiple pending subscription changes into a single, shared reviewSubmission avoid tripping CONCURRENT_REVIEW_SUBMISSION_LIMIT_EXCEEDED, since it reduces the number of reviewSubmission objects created regardless of how many items each one carries? Or does adding items to an already-WAITING_FOR_REVIEW/IN_REVIEW submission trigger a different restriction we should also account for?

Thank you — happy to provide additional logs/request IDs if useful

Answer 1

SKYVIR OP

1d

Not an Apple answer, but I have hit the edges of this from the API side, so here is what I can confirm and what I can't.

What I have seen myself:

A reviewSubmission you create and never submit cannot be released over the API. PATCH /v1/reviewSubmissions/{id} with canceled=true answers 409 "Resource is not in cancellable state" for anything that was never submitted, and there is no DELETE on the resource. My own empty drafts from experimenting are still sitting there.
A submission that came back rejected (UNRESOLVED_ISSUES) does not accept new items either: POST /v1/reviewSubmissionItems answers 409 "reviewSubmission state does not allow adding more items". So "reuse an existing one" has to be limited to READY_FOR_REVIEW, as you wrote.

What another developer reported, not verified by me: unsubmitted drafts do count toward the limit of 5, and the way they cleared theirs was the "Draft Submissions" panel in the App Store Connect web UI, or by adding items into one of the stale drafts and submitting it instead of creating a new one: https://github.com/nulljosh/epiphany/issues/28

So your batching plan looks right to me, with one addition: never create a new reviewSubmission as a retry step. Look up the existing READY_FOR_REVIEW one first (GET /v1/apps/{id}/reviewSubmissions filtered by state) and only create when none exists, otherwise every failed retry leaves a slot-eating draft you can only clear from the browser.

What I don't know: whether 5 is fixed or per-account, and whether Apple ever expires unsubmitted drafts on its own. I have not seen one disappear.