generate SDK with custom header

[kossel]

Description

Hi
Is there a way via either parser or operation, or something where we can inject custom headers? we use Accept-version header to tell sever which version we want, it's part of parameters.header['accept-version'].schema.default is there a way when generating the SDK, it adds that automatically?

export const postApiphotosV1 = <...>(options: Options<..>) => (options.client ?? client).post<...>({
    url: '/api/photos',
    ...options,
    headers: {
        'Content-Type': 'application/json',
        'Accept-version': 1 // it will aways be parameters.header['accept-version'].schema.default
        ...options.headers
    }
});

I looked the documentations but couldn't find out if this is possible. BTW interceptor doesn't work since I would like this to be on build time (when generating sdk.gen) not run time, in runtime we don't have the spec anymore

[pullfrog]

  ^{｜ Build this ➔ ｜ Make a plan ➔ ｜ pullfrog.com}

[dosubot]

Based on my research, Hey API doesn't have built-in support for automatically injecting header defaults from your OpenAPI spec into the generated SDK at build time. Headers are designed to be managed at runtime.

Here are your options:

1. Custom Plugin - You could create a custom plugin that extracts the parameters.header['accept-version'].schema.default value and modifies the generated code. The plugin system provides plugin.forEach('operation', callback) to iterate through operations, though accessing parameter defaults specifically isn't documented in detail.

2. Parser Patch - The parser.patch configuration lets you modify the OpenAPI spec before processing, but it operates at the schema level and won't directly help with operation-level header parameters.

3. Post-Generation Script - As a workaround, you could write a script that runs after generation and modifies the output files to inject the header defaults.

Since you mentioned interceptors don't work for your use case (you want build-time injection), a custom plugin is likely your best path forward, though it would require some investigation into the operation metadata structure to extract the header defaults.

Would you like me to dig deeper into the custom plugin API to see if there's a way to access parameter defaults?

To reply, just mention @dosu.

---

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

  

[mrlubos]

@kossel Dosu gave you a pretty good answer, those are the current options. This is what I'd recommend for now and you can then use the interceptor approach #3269 (comment)

I'll keep the issue open because we'd want to allow you to customize the SDK as you described too

[kossel]

btw, I did some try on the custom plugin approach (with assist of AI), looks like once the node is created it cannot be modify the structure, so what AI proposed was creating wrapper functions with those custom headers, I'm not 100% convinced, do you have example plugins where the node of SDK is being changed? thanks