Transfer tool for assistants enabled breaks the calls/List sdk method

[jpgtzg]

While trying to perform SDK calls using the Vapi's Go SDK to retrieve the calls made by an assitant that has the transfer tool:

assistantCalls, err := VapiClient.Calls.List(context.Background(), &vapiApi.CallsListRequest{
			AssistantId: vapiApi.String(assistant.VapiAssistantId),
		})

I get: cannot be deserialized as a *api.CallDestination error, which is internal to Vapi's Go SDK, not our code. This only happens when the transfer tool is enabled.

[jpgtzg]

Issue: CallDestination UnmarshalJSON fails for transfer responses with extra fields

Summary

The CallDestination.UnmarshalJSON method in the generated Go SDK fails to properly deserialize transfer responses when the API returns additional fields not present in the generated TransferDestinationNumber struct.

Problem Description

When the Vapi API returns a transfer response with type: "number", the response can include additional fields like transferPlan and other properties that are not defined in the Fern-generated TransferDestinationNumber struct. This causes the JSON unmarshaling to fail.

Current Behavior

// This fails when API response includes extra fields
valueTransferDestinationNumber := new(TransferDestinationNumber)
if err := json.Unmarshal(data, &valueTransferDestinationNumber); err == nil {
    // This never executes because unmarshaling fails
}

Expected Behavior

The SDK should gracefully handle API responses that include additional fields beyond what's defined in the generated structs.

Root Cause

The Fern-generated TransferDestinationNumber struct has a fixed set of fields:

• Number (required)
• Message (optional)
• NumberE164CheckEnabled (optional)

But the API response can include additional fields like:

• transferPlan
• Other dynamic properties

Proposed Solutions

Option 1: Update Fern Configuration (Recommended)

Modify the Fern configuration to handle extra properties in the TransferDestinationNumber type definition. This would allow the generated struct to accept additional fields without failing.

Option 2: Custom UnmarshalJSON Logic

Implement custom UnmarshalJSON logic that handles the mismatch between API response and generated struct. This is what we've implemented as a temporary workaround.

Temporary Workaround

We've implemented a fix in our fork that:

1. Detects transfer responses with type: "number"
2. Uses a temporary struct to capture all fields
3. Extracts only the known fields for the TransferDestinationNumber
4. Creates a proper instance with the extracted data

// Example of the workaround
var transferResponse struct {
    Type                   string                 `json:"type"`
    Number                 string                 `json:"number"`
    Message                interface{}            `json:"message,omitempty"`
    TransferPlan           map[string]interface{} `json:"transferPlan,omitempty"`
    NumberE164CheckEnabled *bool                  `json:"numberE164CheckEnabled,omitempty"`
}

Impact

This issue affects users who:

• Use transfer functionality with phone numbers
• Receive API responses with additional fields
• Expect the SDK to handle API responses gracefully

Request

Please consider updating the Fern configuration to handle extra properties in transfer destination types, or provide guidance on the best approach for handling this type of API response mismatch.

Related

• This is similar to other generated SDK issues where API responses include fields not defined in the OpenAPI spec
• The fix should be applied to all transfer destination types, not just TransferDestinationNumber