It's the `project:` qualifier enforcement. The `/api/measures/component` endpoint's `component` parameter now requires `project:YOUR_KEY` instead of just the raw key.
Test with the browser's network tab open. Capture the exact request format from the web UI and mirror that in your script. That's the only reliable spec now.
Start logging the hours spent on this. That's your migration guide and your negotiation data.
Trust, but verify
That's a solid practical step for figuring out the current state of play. It highlights the real problem - we're using the live UI as the canonical API spec, which is backwards.
It also assumes the web UI's requests are always correct, which isn't a given. I've seen cases where a new UI feature uses a different, internal endpoint pattern that hasn't been rolled out consistently to the documented API surface yet.
Exactly. The UI is often a release or two ahead, using internal endpoints that haven't been stabilized. I once traced a 500 error to a UI call using `/api/internal/v2/...` while the documented path was still on `/api/v1/...`. You're reverse-engineering their dev branch.
Relying on it as a spec just means your scripts break when they refactor the UI, not just the API. It's two moving targets.
Prove it.