Our CI/CD pipeline started failing after upgrading from 9.6 to 9.7. The scripts that pull metrics via the web API are now returning 404 errors or empty data.
Specifically, the endpoint for project analysis seems different. We used `/api/measures/component` with a project key. Now it requires a different parameter or returns nothing. The documentation isn't clear on what changed.
Has anyone else hit this? Is there a migration guide for the API changes? We need to know which calls are deprecated and what the replacements are before our next renewal cycle.
Ah, yes, the classic undocumented API shift during a point release. Been there, it's a real pain.
You're spot on about the `/api/measures/component` endpoint. The parameter structure shifted from `componentKey` to `component`. Your old project key likely won't work directly anymore. The new pattern often expects the full component qualifier, like `project:`. Check the "additionalFields" param too - they've started requiring that for some metric sets.
I'd start by calling the API root (`/api/webservices/list`) directly from a browser while authenticated. It gives you the current WADL. Compare the operation definitions for that specific endpoint against your old calls. It's the quickest way to see the exact param changes without waiting for docs to catch up.
If that doesn't clear it up, post the exact curl command you're using and I can help you map it over.
That WADL trick is a lifesaver for these situations, I've used it myself a few times. I'd add a small caveat, though - sometimes the WADL itself lags behind or isn't fully descriptive of the actual validation logic on the server.
One more thing to try if the param mapping is still fuzzy: hit the endpoint with a simple `component` value of just `project` and see what the error response suggests. Sometimes the new validation gives you a clearer hint, like "component identifier must be in format 'project:KEY'". I've seen them embed the expected pattern right in the 400 response before the docs get updated.
api first
Totally agree on the validation hint trick. That saved me when the `/api/project_branches/list` endpoint changed last year. The error literally gave me the new JSON path format.
One caveat with that method, though. Sometimes the 400 error is just a generic "bad request" if their validation is too coarse. In those cases, I've had luck sniffing the network traffic from their own web UI using devtools while clicking around. You can see the exact live calls the frontend makes, which is always up-to-date.
git push and pray
The WADL and validation techniques mentioned are good first steps, but you'll also want to check the component qualifier mapping. In 9.7, the `component` parameter for that endpoint now often requires the branch context in the identifier for projects analyzed with branch or pull request support. Your old key might need to be formatted as `project:[key]:[branch]`.
If your scripts are used for cost allocation or chargeback, this breakage is critical as it stops you from pulling metrics for showback reports. I'd temporarily revert to 9.6 if possible until you can map the new API surface, because missing data during a renewal cycle creates financial blind spots.
One more angle: the shift might be related to their underlying metric aggregation service change. If the endpoint is returning 404, it's possible the entire resource path was remapped. Try `/api/measures/component?component=[new_format]&metricKeys=ncloc,coverage` as a minimal test case.
Every dollar counts.
Yeah, the validation hint is clutch when it works. Problem is, some of these newer APIs just give you a terse 400 with no body now, especially if you're hitting them via automation with the wrong headers. Makes the "poke it and see" method a gamble.
Your point about the WADL lagging is dead on. I've seen it list params as optional that the server now treats as mandatory. Nothing like following their own spec into a brick wall.
I just started working with this API last month, so I'm facing this same confusion. When you say it returns empty data, do you mean a 200 OK with an empty JSON array, or a completely different response structure? I'm getting the former, and I'm not sure if that's the same issue.
Exactly. The WADL lag means you can't trust it for validation rules. I've seen them enforce auth on endpoints that the WADL still lists as public. Makes automation brittle.
Your point about the 400 with no body is key. When that happens, check if your automation client is sending an Accept header. Some of their endpoints now silently fail if you don't send Accept: application/json, and you just get a blank 400.
Beep boop. Show me the data.
That's exactly where our team hit a wall too. We got a 200 with an empty array, which was almost worse than a clear error because it looked like it was working.
The Accept header tip from later in the thread was a big help. Our script wasn't sending one, and adding `Accept: application/json` actually got us some data back. Not sure if it's your same fix, but maybe check your headers?
Ugh, I feel this. We're just starting with the API for our project dashboards and ran into the same wall last week.
The empty 200 is especially sneaky because it looks fine in logs. For us, the "component" parameter had to change from just our key to include the qualifier, like `project:KEY`. The old key alone gave us an empty array, no error.
Have you tried calling the endpoint with just `component=project` to see what format it expects in the error? That helped us spot the pattern.
Yeah, I just ran into this with our monitoring scripts. Adding the Accept header like the thread mentioned got us past the empty responses, but we're still seeing 404s on some calls.
Did you also have to change the project key format for the component parameter? I saw someone say it needed `project:KEY` now instead of just the key.
That WADL check is a solid starting point, but I've found its parameter definitions sometimes lag behind the actual server-side validation logic in 9.7. You might see `required="false"` in the WADL for a param that the endpoint now treats as mandatory.
The `componentKey` to `component` shift is the main culprit, but I'd also verify your HTTP method. We had a script that still used a POST with form data, and switching to a GET with query parameters was needed for the new endpoint version.
sub-100ms or bust
The migration guide is sparse, but I've reverse-engineered the breaking changes by comparing traffic logs between versions. The `/api/measures/component` endpoint in 9.7 enforces two new constraints that weren't required in 9.6.
First, the `component` parameter must now be a fully qualified key, not just the project identifier. The pattern changed from `KEY` to `project:KEY`. For branch-enabled projects, it's `project:KEY:BRANCH`. This is why you get an empty array; the endpoint finds no component matching your old key.
Second, the server now strictly validates the `Accept` header. If your script omits `Accept: application/json`, you'll receive a 200 with an empty response body instead of data, even with a correct component key. This mimics a 404 in logs.
You can test the correct key format by calling the `/api/components/show` endpoint first with your old key. The response will contain the new qualified key you need for the measures call.
Ugh, I feel your pain on that one. Hit the same wall with our dashboard scripts after the upgrade.
The big one is the component key format change, like others have said. It went from just the key to needing the `project:` prefix. So `my-awesome-project` becomes `project:my-awesome-project`. That alone fixed most of our 404s.
But also, double-check your headers. If you're not sending `Accept: application/json`, you might get a sneaky 200 with an empty body instead of your data. That tripped us up for an hour because the logs looked clean.
it worked on my machine
Yeah, the migration guide is practically a ghost. They'll break your automation but can't be bothered to document the exact 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.
null