Path parameter incorrectly serialized as /servers/id,<id> instead of /servers/<id> on paramsStructure flat

[fiftyy]

Description

Hi, I encountered an issue when calling (with paramsStructure flat) a generated GET method. The request path is incorrectly serialized as: /servers/id,1335279038599663729

But it should be: /servers/1335279038599663729

This looks like the {id} placeholder is not replaced properly and the value is appended with a comma.

Let me know if you need any further details or if I can provide additional logs or config.

Reproducible example or configuration

import { defineConfig } from '@hey-api/openapi-ts';

export default defineConfig({
	input: './scripts/openapi-spec.json',
	output: { path: './src/api/client', importFileExtension: '.js' },
	plugins: [
		'@hey-api/schemas',
		{
			name: '@hey-api/typescript',
			topType: "any",
			enums: {
				case: 'preserve',
				enabled: true,
				mode: 'typescript'
			}
		},
		{
			name: '@hey-api/sdk',
			asClass: true,
			responseStyle: 'data',
			paramsStructure: 'flat',
			classNameBuilder: (name) => `${name}Service`
		}
	]
});

OpenAPI specification (optional)

    "/servers/{id}": {
      "get": {
        "parameters": [
          {
            "name": "id",
            "in": "path",
            "schema": {
              "type": "string"
            },
            "required": true
          }
        ],
        "responses": {
          "200": {
            "description": "Ok",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/IServer"
                }
              }
            }
          }
        },
        "tags": [
          "Servers"
        ],
        "security": [],
        "operationId": "GetServer"
      },

System information (optional)

@hey-api/openapi-ts: 0.87.5

[dosubot[bot]]

Based on the documentation, the paramsStructure: 'flat' option in @hey-api/sdk controls how parameters are passed to generated SDK methods, but there’s no mention of a known issue or caveat with path parameter serialization like what you’re seeing—where the path becomes /servers/id, instead of /servers/ reference. The migration and configuration docs also don’t mention this bug or any recent changes that would explain it reference.

To troubleshoot, I recommend checking the generated SDK code for the affected endpoint to see how it constructs the URL and handles path parameters. You could also try switching paramsStructure to 'object' or another value to see if the issue persists, which might help narrow down whether the bug is specific to the 'flat' structure. If you can share a snippet of the generated code for the GET method, that could help pinpoint where the replacement is going wrong.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[fiftyy]

    public static getServer<ThrowOnError extends boolean = false>(parameters: {
        id: string;
    }, options?: Options<never, ThrowOnError>) {
        const params = buildClientParams([
            parameters
        ], [
            {
                in: 'path',
                key: 'id'
            }
        ]);
        return (options?.client ?? client).get<GetServerResponses, unknown, ThrowOnError, 'data'>({
            responseStyle: 'data',
            url: '/servers/{id}',
            ...options,
            ...params
        });
    }

@dosu

[dosubot[bot]]

The issue seems to be that buildClientParams isn't replacing the {id} placeholder in the URL; instead, it's appending the id as a comma-separated value, resulting in /servers/id,. In typical OpenAPI SDKs, path parameters should be injected directly into the URL by replacing placeholders like {id} with the actual value.

To debug, log or inspect the output of buildClientParams and the final URL just before the HTTP request. If buildClientParams doesn't handle path replacement, you may need to manually replace {id} in the url string with parameters.id before making the request. For example:

url: `/servers/${parameters.id}`,

Alternatively, check if there's an update or config option that affects path parameter handling with paramsStructure: 'flat', as this might be a bug or limitation in the current version. If you want to keep the generated code as-is, you could also try switching paramsStructure to 'object' to see if the issue persists.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[fiftyy]

return await ServersService.getServer({ id: "1335279038599663729" }); that is how the function should be called. this pretty looks like a bug from heyapi @dosu

[dosubot[bot]]

You're right—the way you're calling the function is correct, and based on your config and the generated code, this does look like a bug in heyapi's handling of path parameters when using paramsStructure: 'flat'. The docs don't mention this issue or provide a workaround.

As a temporary fix, you could try switching paramsStructure to 'object' to see if it resolves the path replacement, though that will change how you call the SDK methods. Alternatively, you could manually patch the generated code to replace {id} in the URL, but that's not ideal for long-term maintenance.

If you can, logging the output of buildClientParams or the final URL before the request might help pinpoint where the substitution fails. Let me know if you want help digging deeper into that!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[fiftyy]

Logged the output: buildClientParams:

{ path: { id: { id: '1335279038599663729' } } }

[francisco-polaco]

Hello!

I'm also facing this issue. Additionally, flat paramsStructure does not use the body parameter in request.

Any ETA on solving this? This is a blocker on using this library, since the grouped paramsStructure makes the API calls extremely complex.

[CowCatDE]

Hello!

I'm also facing this issue. Additionally, flat paramsStructure does not use the body parameter in request.

Any ETA on solving this? This is a blocker on using this library, since the grouped paramsStructure makes the API calls extremely complex.

Same here, just waiting on the merge to finally implement this

[fiftyy]

Hello!

I'm also facing this issue. Additionally, flat paramsStructure does not use the body parameter in request.

Any ETA on solving this? This is a blocker on using this library, since the grouped paramsStructure makes the API calls extremely complex.

@dosu is that related to the linked pull-request?

[dosubot[bot]]

Based on the official documentation, there’s no mention of a pull request or ETA for a fix to the 'flat' paramsStructure issues with path or body parameter handling, and no documented connection between a pull request and these bugs. The docs also don’t provide real-time PR status or bug fix timelines, so for the latest updates, it’s best to monitor the repository or discussion threads directly citation.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[fiftyy]

Hello! I'm also facing this issue. Additionally, flat paramsStructure does not use the body parameter in request. Any ETA on solving this? This is a blocker on using this library, since the grouped paramsStructure makes the API calls extremely complex.

Same here, just waiting on the merge to finally implement this

Not sure if the merge fixes the flat paramsStructure problem with body parameters.

[mrlubos]

@fiftyy @francisco-polaco @CowCatDE this should be fixed in the next release, mind giving it a try?

[mrlubos]

how did y'all even find this feature, it's purposefully not documented anywhere!