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
