fix(emails): send attachment content type as content_type

Merged
RA
14d ago
+35-17

Summary

CreateAttachment renames its content_type field to contentType when it serializes. The send email endpoint reads the attachment content type from content_type, as the API reference and the other SDKs do, so a content type set with with_content_type never reaches the API and the API derives the type from the filename instead.

For example, an attachment built with .with_filename("invoice").with_content_type("application/pdf") currently serializes as {"path":"...","filename":"invoice","contentType":"application/pdf"}.

The Node SDK fixed the same casing in resend/resend-node#391. This change drops the rename so the field serializes as content_type.

Changes

  • src/emails.rs: remove rename = "contentType" from CreateAttachment::content_type, and add a unit test that checks the serialized key.
  • CHANGELOG.md: add an Unreleased entry under Fixed.

Testing

  • cargo test --lib attachment_content_type fails without the fix (content_type is missing from the JSON) and passes with it, with and without --features blocking.
  • cargo fmt --check and cargo clippy --all-targets (with and without --features blocking) report nothing.

Summary by cubic

Fixes attachment content type serialization so with_content_type values reach the API instead of being ignored.

CreateAttachment previously renamed the field to contentType during serialization, but the send email endpoint expects content_type. The API was deriving the type from the filename instead. This change strips the rename, adds a unit test verifying the serialized key, and updates test assertions to satisfy clippy.