Marshal errors in assistant / call methods

[SoleimanyBen]

When trying to list either assistants or calls, a marshal errors occurs

Listing assistants:

json: cannot unmarshal string into Go struct field .embed.startSpeakingPlan.smartEndpointingEnabled of type map[string]interface {}

Listing calls:

 {"cost":0,"type":"knowledge-base","model":{"model":"gemini-1.5-flash","provider":"google"},"promptTokens":0,"completionTokens":0} cannot be deserialized as a *api.CallCostsItem

[fern-support]

TL;DR -- Both of these issues appear to be OpenAPI spec inconsistencies.

For now, we'll need to update the OpenAPI spec to resolve these issues. In the future, we can update the SDK so that it better handles API inconsistencies.

Proposed solution

1. Vapi to update the smartEncodingEnabled to match the server type (i.e. string).
2. Vapi to add the knowedge-base type to the /call costs array.

For more details, see the description below.

Listing assistants

The OpenAPI spec defines this schema as an object here:

      "StartSpeakingPlan": {
        "type": "object",
        "properties": {
          ...
          "smartEndpointingEnabled": {
            "type": "object",
            "example": false,
            "deprecated": true
          },

The associated StartSpeakingPlan Go type is shown below:

type StartSpeakingPlan struct {
        ...
	WaitSeconds             *float64               `json:"waitSeconds,omitempty" url:"waitSeconds,omitempty"`
	SmartEndpointingEnabled map[string]interface{} `json:"smartEndpointingEnabled,omitempty" url:"smartEndpointingEnabled,omitempty"`

In this case, the server is responding with a schema that is inconsistent with what Go expects (i.e. a string), so the SDK fails to decode the type.

Listing calls

The API spec doesn't include a variant for the /calls costs array with the knowledge-base discriminant property, so the response fails to deserialize.

Again, we'll need to fix vapi's spec so that it matches the server's behavior.

Future work

We should update the Go SDK so that it doesn't fail fast if the schema is invalid. This is simpler for the CallCostsItem union type, but will require more time to be more broadly applied to cover all cases (like the Listing assistants issue).