Customize methods
Change method names
Speakeasy uses your OpenAPI schema to infer names for class types, methods, and parameters. However, you can override these names to tailor the generated SDK to your preferences.
The x-speakeasy-name-override
extension can be used to override the name of a class, method, or parameter. Depending on where this extension is placed in an OpenAPI schema, names can be overridden at different scopes, such as globally or for specific operations and parameters.
For example, the x-speakeasy-name-override
extension can be used to override the generated name for a method generated from an operation.
This extension can be applied globally by placing it at the root of the OpenAPI schema, allowing all methods with an operationId
that matches the provided operationId
regex to be overridden with methodNameOverride
.
openapi: 3.1.0info:title: Testversion: 0.0.1servers:- url: https://httpbin.orgsecurity:- basicAuth: []x-speakeasy-name-override:- operationId: ^get.*methodNameOverride: get- operationId: ^post.*methodNameOverride: createpaths:/test:get:operationId: getTestresponses:"200":description: OKpost:operationId: postTestrequestBody:required: truecontent:application/json:schema:$ref: "#/components/schemas/Test"responses:"200":description: OK
Since getTest
and postTest
match the ^get.*
and ^post.*
regexes defined by the global x-speakeasy-name-override
extension, these method names will be generated as get
and create
, respectively.
Alternatively, x-speakeasy-name-override
can be used at the operation level to override the generated method name for that specific operation only. If the OpenAPI schema includes the extension at both the global and operation levels, the operation-level extension will take precedence.
Consider the same schema shown above with an operation-level extension added to the get
operation:
---get:operationId: getTestx-speakeasy-name-override: getRandomTestresponses:"200":description: OK
Now, postTest
will be generated as create
as before, but getTest
will be generated as getRandomTest
.
Configuring method signatures
To customize method signatures in an SDK, control how parameters are passed to the method by setting the maxMethodParams
configuration option in the gen.yaml
file.
Here is an example of how to set the maxMethodParams
configuration option in your gen.yaml
file:
configVersion: 2.0.0generation:# ...typescript:maxMethodParams: 4# ...
Here, the maxMethodParams
configuration option is set to 4
, so the generated SDK will have a maximum of four parameters for each method, including the request body parameter.
If the number of parameters for a method exceeds the maxMethodParams
configuration option, the generated SDK will use a single request object parameter to encapsulate all the parameters.
To ensure the generator always creates a request object for an SDK, set maxMethodParams
to 0
. This approach is useful for enabling request objects to evolve gracefully, avoiding breaking changes to the method signature when adding parameters in the future.
Here are examples of an SDK with maxMethodParams
set to 4
and 0
:
// Example of SDK with maxMethodParams set to 4import { Speakeasybar } from "speakeasy";async function run() {const sdk = new Speakeasybar();const ingredient = "vodka";const name = "martini";const limit = 100;const result = await sdk.drinks.listDrinks(ingredient, name, limit);// Handle the resultconsole.log(result);}run();// Example of SDK with maxMethodParams set to 0import { Speakeasybar } from "speakeasy";async function run() {const sdk = new Speakeasybar();const result = await sdk.drinks.listDrinks({ingredient: "vodka",name: "martini",limit: 100,});// Handle the resultconsole.log(result);}run();
You can also set maxMethodParams
using the x-speakeasy-max-method-params
extension in your OpenAPI document, either globally at the root of the document or at the operation level.
The order of precedence for configuration is:
- Operation-level
x-speakeasy-max-method-params
- Global-level
x-speakeasy-max-method-params
- The
maxMethodParams
configuration option in thegen.yaml
file
The configuration set in gen.yaml
or through the extension at the root of the document will apply to all operations unless an operation-level extension overrides it.
Exclude parameters from signatures
To exclude certain parameters from the generated SDK, use the x-speakeasy-ignore
extension.
The following example uses x-speakeasy-ignore: true
to exclude a parameter:
paths:/test/user/{user_id}:parameters:- name: user_idin: pathrequired: trueschema:type: string- name: statusx-speakeasy-ignore: truein: queryrequired: trueschema:type: stringget:operationId: getUserresponses:"200":description: OK...
Exclude methods from an SDK
Use the x-speakeasy-ignore
extension to exclude certain methods from the generated SDK.
The following example illustrates several instances of x-speakeasy-ignore: true
used across a schema.
paths:/test:get:x-speakeasy-ignore: trueoperationId: getTestresponses:"200":description: OK