Enhance JSON unmarshalling in CallDestination to support dynamic transfer types (number and sip) with additional fields handling.

[jpgtzg]

Fix CallDestination UnmarshalJSON for Transfer Responses

Problem

The CallDestination.UnmarshalJSON method was failing to properly deserialize transfer responses with type: "number" when the API response included additional fields not present in the generated TransferDestinationNumber struct.

Root Cause

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

• Number (required)
• Message (optional, of type *TransferDestinationNumberMessage)
• NumberE164CheckEnabled (optional, of type *bool)

However, the API response for transfer destinations with type: "number" can include additional fields like:

• transferPlan (map[string]interface{})
• Extra properties not defined in the generated struct

The original code attempted to unmarshal directly into TransferDestinationNumber, which would fail when these extra fields were present.

Solution

Modified the UnmarshalJSON method in calls.go to:

1. Detect transfer responses with type: "number" early in the deserialization process
2. Use a temporary struct that captures all possible fields from the API response
3. Extract only the known fields that match the TransferDestinationNumber struct
4. Create a proper TransferDestinationNumber instance with the extracted data
5. Handle optional fields gracefully by checking for their presence before setting them

Key Changes

• Added proper handling for the message field by attempting to unmarshal it as TransferDestinationNumberMessage
• Made NumberE164CheckEnabled optional and properly typed as *bool
• Preserved the fallback logic for cases where the type field is not present
• Maintained backward compatibility with existing API responses

Testing

The fix has been tested to:

• ✅ Compile successfully with go build ./...
• ✅ Handle API responses with extra fields gracefully
• ✅ Preserve all known fields from the TransferDestinationNumber struct
• ✅ Maintain backward compatibility with existing responses

Impact

This fix resolves the deserialization issue for transfer responses while maintaining the integrity of the generated SDK structure. The change is minimal and focused, affecting only the specific case where transfer responses with type: "number" include additional fields.

Related Issues

This addresses the problem where users were getting deserialization errors when the API returned transfer responses that included fields beyond what the generated struct expected. #8