[RaphaelFakhri]

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.

^{Written for commit 601580e. Summary will update on new commits.}

[AntoniosBarotsis]

LGTM, thanks for the heads up and apologies for the delay, I've been busy the last few days. I'll talk to the team and make sure this is how it should function before releasing but that shouldn't take long (probably expect a release tomorrow at the latest).