Errors, limits, and retries

Validate locally before submission: the input must exist and be a .jar or .zip. The hosted service limits uploads to 50 MB, expanded archives to 128 MiB, each archive entry to 32 MiB, entries and classes to 10,000 each, nested archives to depth 4, and compression ratio to 100:1. A request may select at most four distinct expanded platforms.

The customer API limit is currently 300 requests per minute per authenticated identity or client bucket. A 429 response includes Retry-After. If a build exceeds its API key's per-period NCU ceiling, Retry-After is the ceiling-rounded number of seconds until that key's credit-refresh period ends; the response params also includes retryAfterSeconds and usagePeriodEndsAt. A submission may also be rejected for insufficient NCU or plan concurrency. Application-handled validation errors use the code, message, error, params, and violations envelope. Request binding failures produced directly by Spring can use its framework envelope instead. Security-generated 401 and 403 responses currently contain only error; clients must branch on status and content rather than assuming one universal error shape.

For a polling GET, retry only 429, 502, 503, and 504, honoring Retry-After within a total deadline. Do not retry the submit POST. SUCCESS permits download; FAILED, CANCELLED, deadline expiry, malformed responses, and unknown status values are failures. Preserve the task ID and server error message for diagnosis, but never continue after an unrecognized status.

Do not infer retryability from an undocumented response body or redirect. Fail closed, keep the input artifact unchanged, and require a deliberate human decision before a new paid submission.