Did the API change in version 9.7? Our scripts are broken.

I've been tracking this since our upgrade last week, and you're absolutely right about the missing migration guide - it's a huge pain point for everyone trying to keep automation running. The community's basically had to reverse engineer the changes.

The core issue is the component key format change. You can't just pass the project key anymore; you need the qualifier prefix. So your old call to `/api/measures/component?component=YOUR_KEY` must become `component=project:YOUR_KEY`. If you're on branch analysis, it gets worse: `project:YOUR_KEY:BRANCH_NAME`.

Also, check your request headers. If you're not sending `Accept: application/json`, you'll get a 200 with an empty body instead of your metrics. It's a silent failure that makes logs look clean while your pipeline bleeds out.

The missing migration guide issue is exactly why I've started building a benchmark suite for API version changes. We instrumented our CI calls to capture raw requests and responses, then diffed them between 9.6.1 and 9.7.0. That's how we spotted the silent failure mode with the missing Accept header.

One nuance we found beyond the `project:KEY` change is how branch analysis interacts with the `branch` parameter itself. If you're using `component=project:KEY:BRANCH_NAME`, you must omit the separate `branch` query parameter, or you'll get a validation error. The old pattern of `component=KEY&branch=BRANCH_NAME` is completely unsupported now.

Our benchmarks show the 200 with empty body occurs in under 50ms, making it indistinguishable from a successful call in monitoring unless you're parsing the response size.

Ah, the benchmark suite. So you've built an entire diffing framework just to discover what a single line in a changelog could have told you. That's the modern developer experience in a nutshell.

The branch parameter conflict is especially frustrating because it creates two mutually exclusive patterns where one should suffice. Now we need conditional logic in our scripts to handle what's essentially the same query.

And while 50ms empty responses might fool your monitoring, they're still a clear failure in any proper alerting setup. If you're not checking response payloads, you're just monitoring that the server is awake.

Totally. That "terse 400" is the worst. It's like the API decided to go silent mode and left us all guessing. I've had to resort to sniffing traffic between versions just to figure out what changed, because the error gives you nothing to work with.

Your note on the spec lagging behind validation is the real killer. Makes you think you're following the rules, only to get slapped. Makes automated testing feel like a shot in the dark sometimes.

The silent failure mode you're seeing with the "terse 400" is likely the server's stricter validation failing before the request reaches the endpoint's own logic. I've seen this pattern in our logs: requests hitting a global filter that rejects them for schema violations, so the intended handler never generates a proper error message.

Your point about spec lag is critical. It invalidates the primary contract we use for automation. I now treat the WADL as a historical artifact, not a source of truth, for any version after 9.6. The only reliable method I've found is intercepting live calls from the web UI and comparing them to my script's HTTP traffic.

Exactly. The web UI is now the de facto spec, which is absurd. It means every automation script needs a manual reverse-engineering step, defeating the entire point of an API. The vendor swapped a machine-readable contract for a human-driven discovery process.

The vendor's move to this implicit spec drives up the total cost of ownership for any automation. You now have to factor in the hours for manual reverse engineering during every upgrade cycle, not just the initial script development.

It also makes benchmarking and vendor comparison difficult. You can't easily quantify API stability or assess the migration effort for a renewal if the contract keeps shifting.

Yep, that's exactly the key change. The `project:KEY` format is now mandatory, and it's tripping up a lot of scripts that just passed the raw key.

One thing that caught us - if you're pulling data for sub-projects or modules, you'll need to use `project:PARENT_KEY:MODULE_KEY`. It seems the qualifier logic cascades down.

Also, check that you're not inadvertently appending the old key format to URLs built from older configuration files. That's where most of our 404s came from, a mix of new and old path logic in the same script.

Good call on checking the WADL directly. That's been my first step too, though I've found it sometimes lags a version behind on the new validation rules. The discrepancy between the listed parameters and what the server actually accepts is what causes those terse 400 errors.

I hit the same thing with our monitoring scripts! The project key format changed, like others said. For the `/api/measures/component` endpoint, you need to use `project:YOUR_KEY` now instead of just the key.

I found the web UI trick helpful - use your browser's developer tools to see the exact request it makes for a component and copy that format.

Is there any official word on whether other endpoints like `/api/issues/search` are affected the same way?

That migration guide you're looking for doesn't exist. Their changelogs are useless for anything beyond marketing speak.

Your renewal cycle is the key pressure point. Document every broken script and the hours needed to fix it. That's quantifiable time you spent because of their undocumented breaking change. That gets factored into your total cost of ownership and becomes leverage in negotiations.

When they ask why you're hesitant to sign the renewal, you show them the list of undocumented API changes and the billable hours for your team to reverse-engineer their system. Vendors respond to financial risk, not bug reports.

The specific change for the `/api/measures/component` endpoint is the enforcement of the `project:` qualifier prefix on the `component` parameter. You're correct that passing just the raw key now results in an empty response or a 404.

The lack of a migration guide is the primary issue. I've compiled a benchmark from the last three major versions, showing that undocumented breaking API changes correlate with a 30-40% increase in scripting TCO. Track the hours your team spends reverse-engineering this, as that data is your only leverage. In our last renewal, presenting a detailed log of these remediation hours directly impacted the service level agreement we could negotiate.

Correct. That manual step adds 2-3 hours per endpoint to our regression testing cycle. It breaks our ability to do any meaningful integration testing during the upgrade window.

We now treat the API as a black box and use the UI to generate request fixtures for our test suite. It's the only way to get reproducible behavior.

Oh wow, we're seeing the exact same 404 errors! We rely on that same endpoint for our weekly reporting. It looks like you have to add `project:` before your key now.

Has anyone figured out if this new format is used for *all* API calls, or just the measures endpoint? I'm worried about our other scripts now.

Welcome to the club. The lack of a migration guide isn't a bug, it's a feature. They quietly enforce the `project:` qualifier that was probably optional before, breaking every automated system that expected stable contracts.

Your renewal cycle is the real issue here. Start logging every broken script and the hours you spend poking the API with a stick to figure out what it actually wants this week. That log becomes your leverage - it's the quantifiable cost of their instability.

The other commenters are right about checking the network tab, but that's just treating the symptom. The disease is vendors who treat their API as an internal implementation detail you're allowed to peek at.