fix: allow null contact first_name and last_name on webhook events

[gabrielmfern]

The response types are already right. Contact in contacts/interfaces/contact.ts uses string | null, fixed in #757. Only the webhook payload lagged, where ContactEventData had:

first_name?: string;
last_name?: string;

? is the wrong axis on its own. It says the key may be absent, while still promising a string whenever the key is there. The API sends null, which is the case that type rules out, so event.data.first_name narrows to string after a truthiness check but can hold null at runtime.

Changed to first_name?: string | null, keeping both halves, because for this payload both are real:

• Absent: the contact.created fixture in resend-dotnet has a data object with only id, created_at, updated_at, email, and unsubscribed. The OpenAPI required list agrees.
• Null: the API returns null for a contact with no name. This repo's own __recordings__ carry "first_name":null in 12 HAR fixtures, though those are the REST endpoints rather than webhook deliveries.

string | null is already used for nullable fields in this same file, on filename, content_disposition, content_id, and source_id.

Verification

tsc --noEmit is clean and the 80 tests across src/webhooks and src/contacts pass.

Related

Spec fix in resend/resend-openapi#91, which makes ContactEventData.first_name nullable there too.

Ref DEV-1625

---

Summary by cubic

Allow webhook contact fields first_name and last_name to be nullable as well as optional to match the API and DEV-1625. Previously they were optional but non-nullable; now both can be absent or null, preventing incorrect string narrowing when the API returns null. No runtime behavior change.

• Update ContactEventData in src/webhooks/interfaces/webhook-event.interface.ts to first_name?: string | null and last_name?: string | null (aligns with existing Contact types and OpenAPI).
• Bump resend to 6.20.1.

^{Written for commit 3abf777. Summary will update on new commits.}

Version bump

Includes a patch bump to 6.20.1 in package.json. This repo normally bumps in a separate chore: PR, so drop that commit if you would rather keep the split.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/resend@1073

commit: 3abf777

[cubic-dev-ai]

cubic analysis

No issues found across 1 file

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

Linked issue analysis

Linked issue: DEV-1625: Allow nullable contact first and last names in OpenAPI

Status	Acceptance criteria	Notes
✅	Contact first_name allows null	The webhook event interface changes first_name from optional string to optional string | null.
✅	Contact last_name allows null	The webhook event interface changes last_name from optional string to optional string | null.

<sub>Auto-approved: Type-only fix aligning webhook contact first_name/last_name with the API's nullable payload; no runtime, operational, or behavioral change, and it matches existing nullable fields in the same file.

Re-trigger cubic</sub>

Approval not submitted

This repository is configured to approve as @klotty, but that approval identity is unavailable.
The refresh token passed is incorrect or expired.

cubic left this as a normal review comment instead of falling back to a Cubic App approval.

[cubic-dev-ai]

0 issues found across 1 file (changes from recent commits).

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

<sub>Auto-approved: Type-only fix aligning webhook event fields with the API's null payloads; no runtime or operational change. Version bump is a routine patch release. No human tradeoff remains.

Re-trigger cubic</sub>

Approval not submitted

This repository is configured to approve as @klotty, but that approval identity is unavailable.
Reconnect or verify the approval identity in repository settings.

cubic left this as a normal review comment instead of falling back to a Cubic App approval.