Describe the Bug

There's a type mismatch between the TypeScript interfaces and the actual runtime behavior for contact name fields first_name and last_name. There are two separate but related problems:

1. GET Response Types Don't Match Reality

The GetContactResponseSuccess interface declares first_name and last_name as optional strings. However, the API actually returns null when these fields are not set, not undefined, breaking the TypeScript contract.

2. UPDATE Options Don't Support Clearing Fields

The UpdateContactOptions interface also declares firstName and lastName as optional strings. But in practice, passing null is the only way to clear these fields:

• Passing an explicit undefined (or omitting the field) leaves the existing value unchanged
• Passing an empty string '' sets the field to an empty string (not null)
• Passing null clears the field back to null

This null behavior isn't reflected in the types, so TypeScript users have no way to clear these fields without a type assertion.

Link to the code that reproduces this issue

https://github.com/TyMick/resend-node/blob/aaf05554ddad5b4162cc96948698e5d80f093ad9/contacts-test-script.mjs

To Reproduce

The test script linked above demonstrates all these behaviors. To run it yourself:

1. Pass a real API key to Resend() in place of my redacted one
2. Replace my audience ID with one of your own
3. Place the script in the root of your resend-node repo
4. pnpm build
5. node ./contacts-test-script.mjs

Expected Behavior

Here are the possible solutions that have come to my mind, but I'm not sure which approach you'd prefer:

1. Update the TypeScript interfaces to include null where applicable
   • Change first_name?: string to first_name: string | null in GET responses
   • Change firstName?: string to firstName?: string | null in UPDATE options
2. Normalize null to undefined at the SDK level—though this might be tricky for UPDATE requests where distinguishing between "not provided" and "explicitly clear this field" is important
3. Change the API behavior to not return null in GET responses (though this would be a breaking API change)
4. Treat null and empty strings the same—though the current distinction might be intentional

I lean toward option 1 (updating the interfaces), personally, as it's the least breaking and accurately reflects the API's actual behavior.

What's your node version? (if relevant)

v24.8.0