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.0
info:
title: Test
version: 0.0.1
servers:
- url: https://httpbin.org
security:
- basicAuth: []
x-speakeasy-name-override:
- operationId: ^get.*
methodNameOverride: get
- operationId: ^post.*
methodNameOverride: create
paths:
/test:
get:
operationId: getTest
responses:
"200":
description: OK
post:
operationId: postTest
requestBody:
required: true
content:
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: getTest
x-speakeasy-name-override: getRandomTest
responses:
"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.0
generation:
# ...
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 4
import { 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 result
console.log(result);
}
run();
// Example of SDK with maxMethodParams set to 0
import { Speakeasybar } from "speakeasy";
async function run() {
const sdk = new Speakeasybar();
const result = await sdk.drinks.listDrinks({
ingredient: "vodka",
name: "martini",
limit: 100,
});
// Handle the result
console.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 the gen.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_id
in: path
required: true
schema:
type: string
- name: status
x-speakeasy-ignore: true
in: query
required: true
schema:
type: string
get:
operationId: getUser
responses:
"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: true
operationId: getTest
responses:
"200":
description: OK